CODEWITHSUNDEEP
javadomain-driven-designmicroservicescqrsevent-sourcing
Ali_Nass
Ali_Nass

Reputation: 928

Best Practices for Micro-service interaction with Event-Sourcing (CQRS)

I have an API call that will need to work with more than one aggregate. I have the 2 below ideas in my head to how it should be interacting with the aggregates but I'm open to other ideas.

Is it good practice to send commands from one microservice to another one? Or is it better to have an event handler on microservice B that reacts to events from service A and generates the command all within the microservice B?

Upvotes: 2

Views: 889

Answers (2)

Eben Roux
Eben Roux

Reputation: 13246

Why not both?

I approach these "micro-services" slightly differently. I usually have a messaging endpoint for each bounded context. I guess this fits in nicely with the micro-service idea and that endpoint only responds to commands sent to it that apply to that BC. It would then also publish the relevant events.

What I then may also have is an orchestration endpoint that responds to process managers that "belong" to the relevant BC. This endpoint only deals with the state of the process managers and issues commands to whichever BC messaging endpoint it needs to talk to. For instance, after an OrderRegisteredEvent has been received a SendEMailCommand may be issued. OK, that is more of a technical endpoint/BC but none-the-less.

On the BC-only messaging endpoint there is absolutely no between the different BCs. It is only there to service its own BC.

I hope that makes sense.

Upvotes: 1

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57194

Is it good practice to send commands from one microservice to another one? Or is it better to have an event handler on microservice B that reacts to events from service A and generates the command all within the microservice B?

An important thing to recognize in a service architecture: we want the services to be autonomous. So A should continue working while B is down for maintenance, and vice versa.

This implies that we need to support asynchronous messaging from A to B.

Current "best practice" is that you are dealing with messages being delivered asynchronously, then the semantics should be past tense: SomethingHappened at A, and B will react to it, or not, in its own time at its own discretion.

Does it matter? Hard to say -- handle(Event) is a command, CommandReceived is an event.

Note: this is really just services and messaging -- Event-Sourcing/CQRS really don't enter into it.

Martin Fowler described Domain Events in 2005.

Each Domain Event captures information from the external stimulus.

If you think of A as being external to B (which makes sense, if there are service boundaries between them), then the semantics of the Domain Event pattern may be a very good fit.

Upvotes: 2

Related Questions