I’ve got a few questions… (using Axon v3).
1.) I’m using the DistributedCommandBus
In my case, my command creates the actual aggregate, hence i don’t really have an aggregate identifier yet.
If i omit the @TargetAggregateIdentifier annotation, the command bus routing doesn’t know how to route the command.
Could someone give me some insight into how the distributed command bus uses the Aggregate identifier to make decisions…
Maybe that will help me understand what i need to do in the scenario above.
2.) Is there any way i can use the simple command bus for command execution, but defer event execution to the distributed bus? Or even better, based on the command, decide which implementation to use?
3.) My last question relates to handling broadcast events. I’m hoping to use the Axon event handling to maintain read projections. The problem i foresee is, if i scale these projections, but each one is listening for events, how do i prevent duplicate aggregate processing… :(. I’ve seen mention of ‘locking’ strategies and using the DB itself to perform uniqueness checks. Is this the only way? Could someone point me to possible recipe’s in this area?
4.) I really love the real-time command/event handling that jgroups gives axon. A scenario i’ve been thinking of however is, what if all the target event listeners are offline. In my head, I’ve categorised the event (bus) processing as either real-time (jgroups) or polling based (rabbit, time based jpa queries, etc). So, as i said, what happens if my services that use jgroups are offline. When they come back online do they read from the event store to catch up automatically? On the other hand, polling based event handling will automatically handle the scenario… How should i handle this? (I’m really hoping this is something Axon will do for me already…)