Integrating Distributed Systems composed of a different bounded contexts

[Prakhyat Mallikarjun]

Team,

We are building app on the approach DDD/CQRS/Event Sourcing. 

Did you anytime have a look at this challenge http://abdullin.com/post/dddcqrs-challenge-integrating-distributed-systems/ ?

What are your thoughts and solutions? We are facing similar problem of communicating across bounded context's, looking forward for insights wrt Integrating Distributed Systems composed of a different bounded contexts and applications?

-Prakhyat M M

[Olger Warnier]

Hi Prakhyat, 

I'd use persistent actors with cluster sharding. 

You can start the the ClusterSharding system for different typenames that reflect a bounded context - or - a single aggregate root (in our situation)

like:

ClusterSharding(system).start(

      typeName = AggregateRootNameHere

And have these used between the bounded contexts by sending the AggregateRootName actors messages. 

One practical point for this approach: Currently you have to start your shard types all within the same JVM (at least for your leading node) otherwise the shardcoordinator gets issues. (I am currently changing the BlogApp sample in order to show this behaviour, but many things todo.. so that takes some time0

Kind regards, 

Olger

[Prakhyat Mallikarjun]

Hi Olger,

Thanks for you insights. 

We can make use of ClusterSharding for communication across bounded context, but it will be asynchronous.

Consider if we want updates across bounded context to be synchronous, just messaging via cluster sharding wouldn't help.

I have browsed across group for many answers like use Saga,Process manager or Stream Line object modeling. 

But no single concrete answer for this problem and workable solution. 

Also lets says to complicate the problem further, consider every bounded context is different application deployed in different JVM's. The cluster sharding again wouldn't help.Also how to do updates in sync when bounded contexts are deployed in different JVM's?

-Prakhyat M M

[Olger Warnier]

Hi Prakhyat, 

When you use the ‘ask’ / pipeTo pattern, it can all be sync, kills your performance though. So when the load won’t be too high, that may be an option. Personnaly, I’d check if an async approach is possible in any way. 

Kind regards, 

Olger

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to a topic in the Google Groups "Akka User List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/n96K9ZHJXe8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[Prakhyat Mallikarjun]

Hi Olger,

That would be great....will look forward to your response on "async" approach.

I have never used "pipeTo", I am not at all aware of this? Please suggest me some good articles to understand this.

I have read "ask" is not recommended in production system due to various issues. What are your thoughts on this? This will help me a lot, if at all I will start using "ask" in my code. Do you recommend using "ask"?

-Prakhyat M M

[Matteo Moci]

Hi Prakhyat, 

Can't say I'm an expert about akka and ddd, but here's my 2 cents. 

I agree with Olger, since when I design bounded contexts and follow ddd principles, the first thing that I try to do is to switch to an eventually consistent mindset and integration, that often involves asynchronous code. 

I do this since integrating 2 bc in a synchronous way (e.g. the same transaction) would lead to some really constraining problems for the business: just think what would happen if operations in one bc could fail if a remote bc is down for maintenance. 

Is it ok to fail the first operation and, say, report the error to the user? 

Could the first bc go on with his business being confident that the other bc will catch-up in a while in some way?

Would be better to try to submit the command to the remote bc, and if it fails for some reason, retry it after a while? 

Anyway, each bc should use the most appropriate design for this, and the Vaughn Vernon's book Implementing DDD has really some really clear examples about it. 

Best, 

Matteo

You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.

To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

--

Matteo Moci
http://mox.fm

[Olger Warnier]

Hi Prakhyat, 

I'd recommend async. 

With regards to the pipeTo, I have no current experience with that but saw it passing by in a conversation on the list (and made a mental note to have a look at that)

The 'ask' forces more sync (style) operations (although you can use futures with it.). Most of what we build is async, but some things need an answer, currently use 'ask' for that. (although you might fire a message and thereafter listen to an event based on some correlationId if you really don't want todo this)

We have a lot of akka in production (network of charge points for electric cars), but that is all without the persistence but with the different patterns and that works fine. 

Kind regards, 

Olger