We are working on a building a new system (.Net) which will merge the client's existing 6 systems into one. The current 6 systems all have different databases. While discussing the design of the Web API, the client asked if we could follow the CQRS pattern. I was planning to use one Web API, breaking up the Controllers to Query and Command ones which in turn work with services (c# classes) which are also broken into Query and Command ones.
During one of the meetings, another developer mentioned we should look at microservices since the client mentioned CQRS. Are those two connected, I mean do you need microservices for that? I thought microservices would be overkill here, as there will at the end be one application with one database, not 6 independent systems which could share multiple APIs. Only advantage I could see with microservices would be deployment, but aside from that a single API I thought was ok.
CodePudding user response：
You're facing a classic problem. Do we keep something together for cohesiveness sake or do we separate it for some reason.
In your case you're facing a physical boundary: does the "read side" and "write side" share enough that it is worth homing them within the same physical boundary (a single unit of deployment) or is it worth homing them in two separate physical units (two units of deployment).
In a CQRS scenario, physical separation makes sense for a few reasons
- The models are often different. The read-model is optimized for what is presented to the user, or to a system that needs information, while a write-model is typically richer because it modifies the domain, requires validation, and application of other business rules.
- Reads are typically surfaced more often in a solution, and so require a different set of scaling factors. These factors can be dealt with when they can be independent of the write-side.
Further, if your CQRS is "pure" or close to it, it means the "modify" accesses are going to hit a different data store than your "read" accesses.
Even if they hit the same store, there may still be a reason to separate them. In the cloud world, that does mean separate microservices.
That said, an approach I've come to see as working well is this: create your logical solution around the different needs.. Create your physical solution, initially, to co-house these logical needs in the same space (e.g. one microservice). If scale, performance, testing, coupling or other forces suggest a physical break, then take it! Go for separate microservices.
In the end, it comes to does the thing work, and work well now or forever in a single microservice (deployment unit) or does it work better later, in separate physical instantiations (microservices).
In conclusion, the logical setup/implementation should require some thought up-front most definitely. The physical should be thought of as well, but it is less important initially. When teasing apart the logical structure into physical homes, you'll find that easier to do than if you had started out with the physical structure initially.