Search code examples
domain-driven-designmicroservicescqrs

Domain / integration events payload information in DDD CQRS architecture

I have a question about the integration events used in a microservice / CQRS architecture.

The payload of the event can only have references to aggregates or can it have more information?

If only reference ids can be sent, the only viable solution is to bring the rest of the information with some type of call but the origin would have to implement an endpoint and the services would end up more coupled.

ex. when a user is created and the event is raised. 

UserCreated {
   userId
   name
   lastname
   document
   ...
}

Is this correct?

Solution

  • If only reference ids can be sent,

    Why would only that be allowed? I have worked with a system which was using micro-services, CQRS and DDD(similar like yours) and we did not have such restrictions. Like in most cases it is: "What works best for your application/business domain". Do not follow any rule blindly. This is perfectly fine to put other information in the events Payload as well.

    the only viable solution is to bring the rest of the information with some type of call but the origin would have to implement an endpoint and the services would end up more coupled.

    This is fine in some cases as well but this brings you to the situation to have additional call's after the event has been processed. I would not do this unless you have a really heavy model/models and it would affect your performance. For example if you have an event executed and based on userId you would need to load a collection of related objects/models for some reason. I had one similar case where I had to load a collection of other objects based on some action on user like event UserCreated. Of course in this case you don't want to send all that data in one Event payload. Instead you send only the id of the user and later call a Get api from the other service to get and save that data to your micro-service.

    UserCreated {
    userId
    name
    lastname
    document
    ... }

    Is this correct?

    Yes this is fine :)

    What you could do instead:

    Depending of your business scenario you could publish the information with multiple events with Stages and in different States. Lets say from UI you have some Wizard-like screen with multiple steps of creation. You could publish

      1. event: UserCreatedDraft with some initial data from 1st Wizard page
      1. event: UserPersonalDataCreated with only part of the object related to private data
      1. event: UserPaymentDataCreated with only the payment data created
      1. UserCreatedFinal with the last step

    Of this is just an example for some specific scenario which depends on your use case and your Business requirements. This is just to give you an Idea what you could do in some cases.

    Summary:

    As you can see there are multiple ways how you can work with these kind of systems. Keep in mind that following the rules is good but in some cases you need to do what is the best based on your business scenario and what works for some application might not be the best solution for your. Do what is most efficient for your system. Working with micro-services we need to deal with latency and async operations anyways so saving some performance on other parts of the system is always good.