2
votes

I have a simple scenario regarding CQRS and DDD in mind and I can't figure out the right way to implement it:

Order and Buyer are two aggregate roots inside Ordering service. When a user checks out the basket:

  1. An integration event is raised in (basket) service.

  2. It's handler inside Ordering service gets called.

  3. Inside this handler, a CreateOrderCommand is created and dispatched.

  4. The command handler instantiates an "Order".

  5. As the result, a domain event is raised "OrderStartedDomainEvent".

  6. Inside it's handler, the side effects regarding other aggregates (e.g. Buyer) must be applied: A Buyer is instantiated (if not exists already).

So, after this scenario, I want to change the order state. Changing order state requires a command. Where am I supposed to dispatch this command? From what I read so far, it's not appropriate to create and dispatch the command inside domain event handler.

Also, if I need to raise a domain event here, how can I do that? Since the Buyer constructor may not get called (if it already exists). So is it correct to raise a domain event inside a domain event handler?

I searched a lot but the previous answers were so complicated for me . I'd appreciate if someone clarifies. Thanks in advance.

1
@MaximeGélinas Thanks for the good references you mentioned regarding saga. But in my case, saga won't help since these command are all in one bounded context/microservice and should be handled in as single process. So I believe there's no need for saga.Gru97
You're right. A saga is overkill if you're in a single process. Then a process manager might be the solution (i.e. a stateless saga). A process manager task is to listen for an event and send a command. (It's a fancy name for an event handler which send a command.)Maxime Gélinas

1 Answers

1
votes

From what I read so far, it's not appropriate to create and dispatch the command inside domain event handler.

You would probably dispatch the messages from the application event handler. The domain model is pure in memory bookkeeping; the application layer/component is responsible for moving information from one place to another.

A way of thinking about this sort of design is that the application handler is orchestrating messages between a number of components, one of which happens to be the domain model.