Hi Catalin,
Very interesting and very fundamental question in the same time…
I think there are several ways to address and answer your question. And I assume that currently you are looking for the technical integration solution and Bert is pulling you to the strategic design of DDD.
Let me try to help here and put my 5 cents in…
Generally speaking there are three types of messages you can use: Command, Event, Query.
Using command means that your central app pushes changes to the microservices. Using events means that you just use event-streaming by distributing your event bus and the central app is broadcasting the change. Using queries - the single components can subscribe for changes and the central app might implement query subscription handlers pushing the changes. All these solution will technically work (some of them only with and others also without Axon Server).
Now let return back to Bert’s important questions. The distribution your drawn on the diagram is about technical separation of the system components, not about logical. In terms of DDD the strategic design phase is all about modelling your core domain and identification of the bounded contexts and their relationships. The bounded context is your logical boundary - and it is mostly that a technical boundary of deployment is there in case you distribute… you can distribute your bounded context over several microservices even further e.g. to meet some non-functional requirements. The reason why it is so important to understand if the components belong to the same context or not is the question of relationship between them.
If they belong to the same bounded context, they share the same language (domain types, commands, events and queries) and might by synchronized via event stream without any problems.
If they don’t belong to the same bounded context, it is of utmost importance to understand and classify the relationship between them, grade of freedom, independence of modification, life cycle and coupling… In the worst case you will NOT be able to expose your “internal” event stream to the components and have to adapt your means to the official API (commands and queries).
I hope you understand why you need to start from modeling and strategic design… To get further, I would like to understand, WHY you cut the microservices out of your central app the way you did?
What do you expect them to do better as being separated than being a monolith?
If it is like I expect, the event stream from central app is not going to work. You will need to declare a public API of every microservice in terms of commands and queries and solve a multi-context communication. For doing so, there are two approaches: orchestration and choreography.
For an orchestration aspect, you have a special “process” / “orchestrator” entity that is responsible for the communication between the contexts. In doing so, it will be in charge of doing all the translation between the commands and queries of different bounded contexts.
For choreography, there is no central process knowledge, but you translate your internal domain events into “milestone” / “pivot” events and implement components reacting on them.
Your next question is what to use… It depends, but the general rule is: if the communication can fail (not technically, but because of illegal data or state of the application), you will need to be able to react on that (and compensate) and the orchestration is the way to go. If it is all about executing unconditional steps one after another without any compensation, the choreography will work…
I hope I could help a little.
Cheers,
Simon