mvelosop
commented
4 years ago Hi @dmitribodiu,
As usual, that depends on the context.
For example, in a typical e-commerce application it probably makes sense to scale separately the reads from the updates, because you usually have order-of-magnitude differences between them.
However, it's important to keep in mind that when you're using CQRS you have different "models" for the reads and the writes.
The above means that, for the writes side, you can have a bounded context (BC) to enforce every business rule on the updates. But for the reads, you just have a set of DB tables and queries to return what your users need without going through the restrictions imposed by a BC.
To put it in very simple words, since you don't change data when querying, just do it as fast as possible with simple SQL.
So it might make sense to have a microservice just for reads, that you can scale out as required, even in different geographical zones and another one with the writes, hosting the BCs, that can even be in a network restricted zone.
You might find this article on Apply CQRS and CQS approaches in a DDD microservice in eShopOnContainers interesting.
Hope this helps.
We applied a hexagonal architecture to our Inventory Bounded Context. We use CQRS and event sourcing. Is it a good idea to create a separate .exe process for read side for example and scale it separately? Or in general to create a separate .exe process per adapter (hexagonal architecture), i.e to create a separate exe process listening http port, then another one listening service bus queue, then another one which publishes messages to the queue? Or better approach is to create 1 microservice (.exe) process per bounded context and just configure those adapters? and scale it as a whole?