Need help improving a design with aggregate roots

Question

I have the follow scenario:

You need to create a Request before it to become a Shop and to get a Owner Account.

So one day you register a Request. 2 days after a manager reviews and approves your Request and it means that the system have to create the Shop and Owner Account.

In my model, I thought that Request, Shop and Owner Account were 3 Aggregate Roots, but then I read that I cannot update more than one aggregate in one transaction because they may be (and in fact they are, because Owner Account is in an external authentication service) in separated db servers.

The thing is.. I still have a Request, and when it gets approved I need to create 2 aggregate roots, the Shop (with all the shop attributes, I only have some invariants with the data, like the limit of contact emails or phones) and the Owner Account.

Then one Owner Account can be allowed to edit someone else's Shop (like a collaborator)

How could I model it?

Thanks!

Answer 1

From your requirements, my design would be:

Two bounded contexts:

• Shopping: It has two aggregates ( Request and Shop ).

• Authentication: One aggregate ( OwnerAcount ).

There exists eventual consistency:

(1) Request aggregate would have a method "aprove". This method creates the RequestAproved event.

(2) Shopping BC publishes the RequestAproved event.

(3) Authentication BC is a subscriber to this event. It reacts to the event creating an OwnerAcount aggregate.

(4) The constructor method of OwnerAcount aggregate creates the OwnerAcountCreated event.

(5) Auth BC publishes the OwnerAcountCreated event.

(6) Shopping BC is a subscriber to this event. It reacts to the event creating a Shop aggregate.

Transaction creating the Shop aggregate is different from the one that created the Request aggregate.

Here's a diagram:

(Note: There's a message queue for each event type. Another option would be just one queue for all event types)