Hi Friends,
This post is all abut explanation of CQRS pattern in microservices.
CQRS : Command Query Responsibility Segregation
This pattern says, we can use a different model to update information than the model we use to read information.
For some situations, this separation can be valuable, but for more systems, CQRS adds risky complexity.
Non-CQRS Model:
CQRS Model :
In this we have used different models for read (Query) and update (Command) operations.
By different models we mean different object models, probably running in different logical processes, perhaps on separate hardware.
A web example would see a user looking at a web page that's rendered using the Query model. If the user initiate a change, that change is routed to the separate command model for processing, the resulting change is communicated to the query model to render the updated state.
In this case, there is room for considerable variation here:
The in-memory models may share the same database, in which case, the database acts as the communication between the two models. However, they may also use separate databases, effectively making the query-side database into a real time Reporting database.
In this case, there needs to be some communication mechanism between the two models of their databases.
The two models might not be separate object models, it could be that the same objects have different interfaces for their command side and their query side.
CQRS naturally fits with some other architectural patterns:
When to use CQRS:
In particular, CQRS should only be used on specific portions of a system (a Bounded Context in DDD lingo) and not the system as a whole.
BoundedContext:
Bounded Context is a central pattern in Domain-Driven Design.
Domain Driven Design deals with large models by dividing them into different bounded contexts and being explicit about their relationships.
e.g. of Bounded Context:
That's for this post.
Thanks for reading!!
CQRS : Command Query Responsibility Segregation
This pattern says, we can use a different model to update information than the model we use to read information.
For some situations, this separation can be valuable, but for more systems, CQRS adds risky complexity.
Non-CQRS Model:
CQRS Model :
In this we have used different models for read (Query) and update (Command) operations.
By different models we mean different object models, probably running in different logical processes, perhaps on separate hardware.
A web example would see a user looking at a web page that's rendered using the Query model. If the user initiate a change, that change is routed to the separate command model for processing, the resulting change is communicated to the query model to render the updated state.
In this case, there is room for considerable variation here:
The in-memory models may share the same database, in which case, the database acts as the communication between the two models. However, they may also use separate databases, effectively making the query-side database into a real time Reporting database.
In this case, there needs to be some communication mechanism between the two models of their databases.
The two models might not be separate object models, it could be that the same objects have different interfaces for their command side and their query side.
CQRS naturally fits with some other architectural patterns:
- As we move away from a single representation that we interact with via CRUD, we can easily move to a task-based UI.
- CQRS fits well with event-based programming models. It's common to see CQRS system split into separate services communicating with event collaboration. This allows these services to take advantage of Event Sourcing.
- Having separate models raises questions about how hard to keep those models consistent, which raises the likelihood of using eventual consistency.
It also solves a problem:
How to implement a query that retrieves data from multiple services in a microservice architecture?
Solution:
Define a view database that is a read-only replica which is designed to support that query.
The application keeps the replica up-to-date by subscribing to Domain events published by the service that own the data.
When to use CQRS:
In particular, CQRS should only be used on specific portions of a system (a Bounded Context in DDD lingo) and not the system as a whole.
BoundedContext:
Bounded Context is a central pattern in Domain-Driven Design.
Domain Driven Design deals with large models by dividing them into different bounded contexts and being explicit about their relationships.
e.g. of Bounded Context:
That's for this post.
Thanks for reading!!
No comments:
Post a Comment