First off I want to say thanks for all the work you’ve done on the framework. The Reference Guide is not only extremely helpful for learning Axon, but it has been the single most helpful CQRS/ES resource I have come across. Great work.
I’m currently leading an initiative on my team to evaluate Axon for use in a new product. One of our high level plans up to this point was to execute multiple Commands within a single transaction, but after reading the “Binding the Unit of Work to a Transaction” section of the Reference Guide (under 3.4), it’s seems like that may not be an option within Axon, or even the right way to go about things.
I can’t go into too much detail about our business problem, but here are the reasons why we were planning on multiple Commands per transaction:
- Our system is downstream from our external client system(s).
- We receive unbounded streams of semi-structured text-based messages from the external client systems which are snapshots of data from their system, and we need to use this information to construct our application’s state.
- Each of these data-snapshot messages contains some subset of state from the client system which applies to potentially multiple aggregates within our system
- Therefore, our plan is to transform each message into multiple commands in our domain, but keep the transactional boundary aligned with the message supplied by the external system.
- The fact that we are receiving snapshots coupled with the lax and non-discrete nature of the messaging standard we are dealing with makes it hard to discern intent of the external system (i.e. what operation actually happened and what has changed), and this message to command transformation is where the real “dirty work” is intended to happen, allowing us to keep our domain aggregates clean with well defined command interfaces.
You may be able to deduce our project’s domain from these clues, but I hope this makes some sense.
Even with the less than ideal circumstances above, the Command Pattern as implemented by Axon seems like a great fit, with CQRS/ES possibly also playing a key role.
Thanks for your help,
P. S. We may be interested in some consulting in the near future if that’s a possibility and we haven’t already hit a dead end with what we’re trying to do.