java - DDD and messages for Aggregates communication

Question

I'm writing an exercise application using DDD principles in java with spring boot and mongodb. According to DDD, the communication between Aggregates occur only through messaging. At this point Im not distributing the application, all aggregates resides in the same application, so Im simply using the Spring messaging capabilities to exchange messages.

Each aggregate correspond to exactly one mongo document. Each command or operation triggered by an event is guarded by a @Transactional annotation to ensure that the db transaction and the event are processed atomically. I was wondering where should I store the events? Can I store them within the mongo document? Actually, since mongo transactions spans single documents, isn't this the only option?

Next step is to set a periodic task that will read all recent events and publish them to simulate an off thread communication. At this point, probably a good place would be a separate document collection storing the events.

P.S. I'm not taking event sourcing into consideration for the moment, as it seems to be more advanced.

Thank you!

question from:https://stackoverflow.com/questions/65946218/ddd-and-messages-for-aggregates-communication

Answer 1

I was wondering where should I store the events?

The usual line of thinking is that distributed transactions suck; therefore if you can possibly manage it you want to store the events with the aggregate state. In the RDBMS world your events live in a table that is in the same database schema as your aggregate data -- see Udi Dahan, 2014.

If it helps, you can think of this "outbox" of event messages as being another entity within your aggregate.

After this save is successful, you then work on the problem of copying the information to the different places it needs to be, paying careful attention to the failure modes. It's purely a "plumbing" problem at this point, which is to say that it is usually treated as an application and infrastructure concern, rather than as a domain concern.