1

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!

k-ter
  • 958
  • 1
  • 8
  • 20
  • 1
    I think you need to think about eventual consistency and compensatory actions. Ex: You may notify the manager that one of the aggregates have failed, then he clicks some button to fix it. Or some automatic process that checks for insconsistent registrations and fixes it..or some button to the customer, asking him to complete the registration...etc – Guilherme Meinlschmiedt Abdo May 13 '21 at 00:01

1 Answers1

3

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)

enter image description here

choquero70
  • 4,470
  • 2
  • 28
  • 48
  • Sorry, I don't understand what you mean. Could you elaborate more in detail the question/problem you have? – choquero70 May 14 '21 at 08:25
  • I've reformulated my original question to make it more understandable, my first example was not good at all. Could you take a time to read it again and update your first answer? Sorry and thanks! – k-ter May 14 '21 at 19:21
  • While the weekend I was studying a lot and I came to the exact same solution. Reading you gives me so much more confidence about what I'm doing, so thank you so much for your time! – k-ter May 17 '21 at 19:52
  • I kept thinking that we forgot something. To create the shop I need to create the owner first. We forgot to take into account the access from the owner and collaborators... RequestAproved should make an OwnerAccount be created, but.... Shop should be created after those two events. Any idea? – k-ter May 18 '21 at 00:54
  • Well then the creation of a shop is a consequence of the creation of an OwnerAcount. So the event-actions chain changes. I've updated my answer again. – choquero70 May 18 '21 at 03:15
  • Could emitting the event in the OwnerAccount cause that many Shops are created in case that the creation of the account fails and it has to be run again? Because it would cause 2 constructor calls, and 2 events. Should the event be emitted after the OwnerAccount is saved? – k-ter May 18 '21 at 13:41
  • Sorry I've implicitly supposed that events are persisted in the transaction. And then they are published to the queue so if the creation of account fails, the event isn't persisted neither – choquero70 May 18 '21 at 15:35
  • Yes, my mistake. Now, would it be ok to subscribe to RequestApproved event from the Shopping BC and make a call from a Gateway to some Facade in Auth BC, so Auth BC has not to know about Shopping BC? – k-ter May 21 '21 at 19:24
  • AuthBC doesn't know about ShopBC. It knows of "messages" (domain events translation into a well known published language, for example JSON). AuthBC knows of the queue, no matter which BC published the domain event. – choquero70 May 26 '21 at 19:02