How to publish event of a none AggregateRoot object?

user_11505456 0
Viewed 849

So I am using NestJs with CQRS and DDD in a microservices environment with Eventstore and MySql as a database. In NestJS in order to publish an event, the object needs to be of type AggregateRoot. So I am publishing the object returned after saving it to the database in such way that it is of type AggregateRoot.

What I need to do now is just publish an incoming request as-is in an Event and other services will listen to that event without the need for it to be of type AggregateRoot.

Example: I have an incoming Order to the Order-Microservice containing objects needed in other microservices (like Delivery-Microservice and Assembly-Microservice). I don't need to save it in the order-ms to be able to publish it, because it contains data that I don't necessarily need in the order-ms.

The NestJs EventPublisher requires an object to be of type AggregateRoot. How should I publish that event to EventStore?

event-sourcing nestjs cqrs domain-driven-design
2 Answers

It doesn't always require AggregateRoot. enter image description here

user_79743410

It is true that you can trigger events from different locations (as @maciej-sikorski mentions in his reference to the NestJS documentation.

But you have to be careful here, as doing this can easily break common DDD / CQRS concepts and best-practices. In general:

  • Command changes state conceptually in an AggregateRoot, and Event represents this state.
  • AggregateRoot serves as public entrypoint (i.e. 'public API') of your Orders bounded context.
  • Events are part of the domain, and should be related to the aggregate root, once it is committed.

So don't emit Events anywhere outside your domain objects. But it is okay to e.g. apply a DeliveryAddressValidated event to the aggregate root from a value object called DeliveryAddress that ensures all address fields are filled in, and the address exists. Upon committing the Order aggregate root - when the aggregate is in a consistent state - this event could be picked up in the Delivery-Microservice.

Alternatively - given your Order receives information it does not need - you could have a look at rearranging your bounded contexts. I don't know your design, but sticking with Delivery domain, you could have a Saga that waits for OrderRequested event (indicating Order is valid, but delivery address data + validation is not part of this process) and then triggers a DeliverOrder command (or e.g. a ValidateDelivery command) to the Delivery-Microservice.

user_82952830
Related