聚合根引用位于另一个聚合根中

Question

I currently have two aggregate roots - Customer and AddressBook . Both have some invariants that need to be protected. Customer has reference to AddressBook and I am not sure whether that is the correct way to model my domain because one cannot live without the other and since domain objects should be created using factories I feel like I should not allow creation of Customer without AddressBook and vice versa but obviously one needs to be created before the other. Hope it makes sense.

How should I address my problem?

Other question would be: can we create multiple aggregate roots in a single transaction? I've red that it should not be done in case of update.

Answer 1

I currently have two aggregate roots - Customer and AddressBook. Both have some invariants that need to be protected. Customer has reference to AddressBook and I am not sure whether that is the correct way to model my domain because one cannot live without the other

If they really don't make sense without the other, you may want to review the design to see if they are really part of the same consistency boundary.

Can we create multiple aggregate roots in a single transaction?

Technically, yes. It may not be a good idea.

When all of the logically distinct aggregates are stored together, then creating them in a single transaction is straightforward.

But that also introduces a constraint: that those aggregates need to be stored "together". If all of your aggregates are in the same relational database, an all or nothing transaction is not going to be a problem. On the other hand, if each aggregate is persisted into a document store, then you need a store that allows you to insert multiple documents in the same write.

And if your aggregates should happen to be stored in different document stores, then coordinating the writes becomes even more difficult.

I would like to create closely associated AddressBook with him.... Maybe a domain event would be a more suitable option?

Perhaps; using a domain event to signal a handler to invoke another transaction is a common pattern for automating work. See Evolving Business Processes a la Lokad for a good introduction to process managers.