Architectural Pattern CQRS - JUCSE49-Mavericks/Smart-Class-Routine-Management-System GitHub Wiki
Command and Query Responsibility Segregation Architectural Design Pattern:
The Command and Query Responsibility Segregation (CQRS) pattern separates read and write operations for a data store. Reads and writes may take entirely different paths through the application and may be applied to different data stores. CQRS relies on asynchronous replication to progressively apply writes to the read view, so that changes to the application state instigated by the writer are eventually observed by the reader.
Visual Representation:
Key Components of CQRS:
Command Side (Write Model):
- Commands: Requests to change system state (e.g., create, update, delete).
- Command Handlers: Execute business logic for commands.
- Aggregates: Ensure consistency and valid state transitions.
- Write Database: Stores current state (can be normalized).
- Event Sourcing (optional): Records state changes as events.
Query Side (Read Model):
- Queries: Requests to retrieve data.
- Query Handlers: Fetch and return data from the read model.
- Read Models: Denormalized data optimized for fast reads.
- Read Database: Separate store optimized for querying.
Infrastructure:
- Command & Query Dispatchers: Route commands/queries to handlers.
- Event Bus (optional): Syncs command and query models via events.
When to use CQRS?
-
Complex Business Logic: When your domain has complex rules and operations that require clear separation between command (write) and query (read) logic, CQRS can help manage this complexity.
-
Performance and Scalability: If you need to scale reads and writes independently, CQRS allows you to optimize the read model for queries (denormalized for fast access) and the write model for consistency and integrity.
-
High Read/Write Disparity: In systems where read operations far outweigh write operations, CQRS enables separate optimization for read-heavy scenarios, improving performance.
-
Event Sourcing: If you're using event sourcing, CQRS naturally fits, as it allows you to apply events for commands while maintaining a separate read model for queries.
-
Microservices Architecture: CQRS can be useful in microservices where different services handle reading and writing, allowing them to be independently managed and scaled.
-
Separation of Concerns: If you want to maintain clear separation between business logic for commands (modifying data) and queries (retrieving data), CQRS helps by decoupling these concerns.
When CQRS do not work?
-
The domain or the business rules are simple.
-
A simple CRUD-style user interface and data access operations are sufficient.
How CQRS works?
Command Side handles state-changing operations:
- A command is issued.
- The system processes the command.
- Changes are stored in the write model.
Query Side handles data retrieval operations:
- A query is issued.
- The system fetches the requested data.
- The result is returned from the read model.
Benefits of CQRS:
- Separating write activity from ready activities allows you to use the best database technology for the task at hand, for example, a SQL database for writing and a non-SQL database for reading.
- Read activity tends to be more frequent than writing, thus you can reduce response latency by placing read data sources in strategic geolocations for better performance.
- Separating write from read activity leads to more efficient scaling of storage capacity based on real-world usage.
CQRS VS MVC VS MCT VS BCE:
.png)
Conclusion:
Overall, CQRS is a powerful pattern when used in the right context, providing performance and scalability benefits while maintaining flexibility in handling complex operations. However, it should be used judiciously to avoid unnecessary complexity in simpler systems.