After doing some research, here is what I found out: 1) The *Orders* singleton should not be called the aggregate, but should be call the repository 2) The repository is unnecessary in this case when using cluster sharding
In Bold Radius's example <https://github.com/boldradius/akka-dddd-template>, they completely forgo the repository and have two types of nodes. The Http node and the Cluster node. They both instantiate the the cluster shard so each node acts as a cluster sharding region. All messages go through the Http node acting as the gateway and scale the Cluster node was needed. There doesn't seem to be a need for the repository when each entity is mutually exclusive and it helps with the throughput. The shard regions effectively handles the case of retrieving entity from the shard collection. This only leaves the problem with out-of-order messages. Although having an Http node to handle all incoming messages is attractive, it creates the same bottleneck problem as the repository singleton. I would still like to have multiple handlers to increase throughput. I just need to make sure the messages arrive at the entity in order. The suggestion online is to have a sequence number so that the command entity checks of this sequence number and stashs away the message if it isn't consecutive. But this suggestion has drawbacks since you will need to persist the sequence number in the data store journal: a) the sequence number on the read side may be stale b) two messages may be have the same sequence number if the first message that queried the message has not persisted yet The only other way is to ensure the all the messages for a particular entity is handled by one handlers. Such that: a) all messages for entity A is handled by handler A b) all messages for entity B is handled by handler B Here is the solution I thought up: 1) When a handler is created, it will register itself to a singleton called Handler Manager 2) When an actor wants to send a command to entity A, it will query Handler Manager and ask if there are any handlers handling messages to entity A 3) If no, the handler manager will assign a handler to handle 4) The Handler Manager returns the Actor Ref to the actor and all future requests to send command to entity A This has the added benefit of the shard coordination only resolving the shard region once. On Tuesday, December 15, 2015 at 12:09:47 AM UTC+8, Lap Ming Lee wrote: > > I have been trying to understand the CQRS pattern in the Activator > template example > <http://www.typesafe.com/activator/template/akka-with-cqrs-eventsourcing> > > Specifically I am trying to get my head around why there are multiple > command handlers (one for each node) according to the business logic > diagram here: > > > <https://lh3.googleusercontent.com/-1uOV_iD4tXw/Vm7lmZIVUyI/AAAAAAAABVU/N_qgznOw7Xk/s1600/Screen%2BShot%2B2015-12-14%2Bat%2B11.51.16%2BPM.png> > > My confusion stems from the fact that all the commands are coming from a > single node - HTTP. And this node is connected to multiple command > handlers. This to me looks like the Master Worker pattern. When you have > this pattern, it isn't guaranteed that the messages will arrive at the > Aggregate (ie/ Orders) as the order that it was sent out. > > > For example, > > Master node sends message A to command handler A > > Master node sends message B to command handler B > > > When the messages arrives at the aggregate, it could be > > A) message A, then message B > > or B) message B, then message A > > > 1) Won't this corrupt the command entity if the messages don't arrive in > order? > > > A possible solution to this is to use the consistent router. But this > would mean I would be pushing messages to the handlers instead of the > suggest pulling pattern in the Master Worker activator template > <http://www.typesafe.com/activator/template/akka-distributed-workers>. > > > 2) If all the messages arrives at the singleton aggregate, shouldn't the > Http node just directly talk to the the aggregate singleton? Since the > singleton already ensures that the throughput increase with having multiple > handlers is constricted. > > > 3) I also took a look at the Cluster Sharding activator template > <http://www.typesafe.com/activator/template/akka-cluster-sharding-scala>, > and they don't have the aggregate or the command handlers. So it makes me > wonder why shouldn't the Http node talk directly to a single shard region > instead since it also achieves the same results > > > The only possible answer I came up is that order shouldn't matter in > storing command domain events? > > > It would be great if someone with expertise with this can help me out. > Many thanks in advance. > > > > > > > -- >>>>>>>>>> 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 the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
