-
Notifications
You must be signed in to change notification settings - Fork 91
1) For whom is this project?
If you have as requirement at least one of these items below, this is a good starting point for your microservice.
This microservice template comes with SRP and SOC in mind. Given the own nature of CQRS, you can easily scale this application tuning each stack separately.
Having multiple data stores makes this system a Derived Data system, which means, you never lose data, you can always rebuild one store from another, for example, if you lose an event which sync data between the write and read database you can always get this data back from the write database and rebuild the read store.
Domain Model is materialized to Query Models using view materializer. Keeping this as separed component in the query stack allows fully control to mapped properties and fully testable.
Everything comes with some kind of down side. The case of CQRS with multiple databases, to maintain high availability and scalability we create inconsistencies between databases.
More specifically, replicating data between two databases creates an eventual consistency, which in a specific moment in time, given the replication lag they are different, although is a temporary state and it eventually resolves itself.
This example contains a simplified Domain Model, with entities, aggregate roots, value objects and events, which are essential to synchronize the writing with reading database.
The project contains a well-defined IoC structure that allow you unit test almost every part of this service template, besides technology dependencies.
Inside the main layers you going to find Interfaces which are essential for the application, but with their implementations inside their own layers, what allow Mocking, Stubbing, using test doubles.
There's a simple example using Mother Object Pattern and Builder to simplify unit tests and keep it maintainable and clean.