domain driven design - CQRS & Event Sourcing way to handle a single request that needs to generate multiple commands

Question

I am making a genealogy application as I am trying to learn Event Sourcing and CQRS. I have three aggregates in my application: PersonAggregate, FactAggregate, FamilyAggregate. My request from the UI to the Server to add a spouse to a person is:

{
  personId: "", // And Existing Person in the DB
  personInput: {name: "Bob", birthDate: ""} // Input to create a new person in the DB
}

My Family Aggregate listens to the PersonAggregate for events of PersonCreated to keep a record of all people that have been created.

Would it be a good architecture for the UI to call the PersonAggregate to create the person (with the data about it needing to create a partnership between the two people instead of calling the FamilyAggregate), then on the PersonCreated event to put the data the FamilyAggregate will need to know to add the two people as spouses? Or is that a bad design because now the Event has command data in it?

When a person is created, the Person Aggregate also needs to send data to the FactAggregate to create a Fact about the person's birthdate.

question from:https://stackoverflow.com/questions/65902031/cqrs-event-sourcing-way-to-handle-a-single-request-that-needs-to-generate-mult

Answer 1

The need to update multiple aggregates in a single transaction is a sign that aggregate boundaries are wrong. Because an aggregate is responsible for protecting a transaction boundary by definition. And a single event corresponds to a single transaction.

Let's consider how this case is handled in a non-computer world. The business domain is well designed there. Sharpened through centuries to be as robust and simple as it gets.

The point of decision is not a person or a family. It is the church. Metric book is the aggregate. When a priest makes up a decision, he writes it down into a metric book. Everything else - person's documents, genealogy, list of person's facts - are mere read models in the registration bounded context.

They can be aggregates in other bounded contexts. And some service may listen to registration events and update relevant entities after the original transaction is completed and event is written. Eventually.