CQRS (Command Query Responsibility Segregation)

The Command Model is the write-optimized component responsible for processing state-changing operations. It enforces business rules and invariants, ensuring data integrity.

• Commands are imperative requests (e.g., PlaceOrderCommand, UpdateUserAddressCommand) that represent an intent to change state.
• The model validates the command and, if valid, executes it, often resulting in the generation of one or more domain events.
• It is typically built using Domain-Driven Design (DDD) constructs like aggregates and domain services. This model is the system of record for writes.

The Query Model is the read-optimized component designed solely for data retrieval. It is denormalized and shaped specifically for the application's view requirements.

• Queries are simple requests for data (e.g., GetUserOrderHistoryQuery, GetDashboardMetricsQuery) with no side effects.
• This model is often a simple set of Projections or Materialized Views that are populated asynchronously from events emitted by the Command Model.
• It can use entirely different database technologies (e.g., a relational database for commands, a document store or a specialized OLAP database for queries) to maximize read performance.

Domain Events are immutable records of something that has happened within the Command Model. They are the primary mechanism for communicating state changes to the Query Model and other subsystems.

• Events are named in the past tense (e.g., OrderPlaced, UserAddressUpdated).
• They contain the data relevant to the change. In systems paired with Event Sourcing, the sequence of events becomes the system of record.
• Events are published to an event bus or message broker (e.g., Apache Kafka, RabbitMQ), enabling loose coupling between the Command and Query sides.

An Event Handler (or Projection) is a component that listens for published Domain Events and updates the denormalized Query Model accordingly.

• Each handler is responsible for a specific view or data projection. For example, an OrderPlaced event might be processed by handlers that update a CustomerOrderHistory view, a ProductSales view, and a ShippingQueue view.
• This asynchronous processing is key to CQRS's scalability, as it decouples the performance of writes from the potentially complex work of updating numerous read-optimized views.
• Handlers must be idempotent to safely handle event replays.

A defining characteristic of CQRS is the use of physically separate data stores for the Command and Query responsibilities.

• Command Store: Optimized for transactional integrity and write performance. Often uses a relational database with normalized schemas to enforce business rules. In Event Sourcing, this is simply an event store—an append-only log of events.
• Query Store(s): Optimized for fast reads and specific query patterns. Can be any technology: a NoSQL document database, a search index (Elasticsearch), a graph database, or a data warehouse. Multiple query stores can exist for different purposes.
• The separation allows each store to be scaled, optimized, and even replaced independently.

The Synchronization Mechanism is the infrastructure that keeps the separate Command and Query data stores eventually consistent. It is the backbone of the CQRS pattern.

• This is typically implemented using the publish-subscribe pattern. The Command Model publishes events, and the Query Model subscribes to them via event handlers.
• The mechanism must guarantee at-least-once or effectively-once delivery to ensure projections are updated. This often involves durable messaging and idempotent handlers.
• The inherent delay in this asynchronous propagation means the Query Model is eventually consistent with the Command Model. Applications must be designed to handle this brief staleness.

An architectural pattern where the state of an application is determined by a sequence of immutable events, which are stored as the system's source of truth. It is a natural complement to CQRS.

• Core Mechanism: Instead of storing the current state, the system persists every state-changing action as an event. The current state is derived by replaying the event log.
• Synergy with CQRS: The Command side of CQRS generates events, which are then persisted. Query models (projections) are built by consuming these events to create optimized read views.
• Benefits: Provides a complete audit trail, enables temporal querying ("state as of last Tuesday"), and facilitates building new query models from the historical event stream.

A design pattern for managing long-running transactions in distributed systems by breaking them into a sequence of local transactions, each with a compensating transaction for rollback.

• Relation to CQRS: A complex business command in a CQRS system often translates to a saga. Each step in the saga may update a different aggregate or service, publishing events that are consumed by query projections.
• Orchestration vs. Choreography: Sagas can be coordinated by a central orchestrator (sends commands) or implemented via choreography (services react to events).
• Compensating Actions: If a step fails, previously completed steps are undone via application-level compensating commands (e.g., CancelReservation), maintaining eventual consistency without distributed locks.

A consistency model for distributed data stores that guarantees if no new updates are made to a given data item, all accesses will eventually return the last updated value.

• CQRS Implication: This is the typical consistency model between the write (command) and read (query) models. After a command is processed and events are published, there is a delay before query models are updated.
• Trade-off: Accepts temporary staleness in read models to achieve high availability, scalability, and performance on the query side.
• Implementation: Relies on asynchronous message passing (e.g., an event bus) to propagate updates from the command model to the various query projections.

A precomputed query result stored as a physical table (or collection) that is updated from base data. It is the primary implementation mechanism for the Query side in CQRS.

• Purpose: Optimizes read performance by transforming and aggregating data into a shape perfectly suited for specific queries, eliminating complex joins at query time.
• Maintenance: In CQRS, these views are maintained by projection processes that listen to events from the command model and update the view accordingly.
• Example: An OrderSummary view containing customer name, total cost, and item count, built from OrderCreated, ItemAdded, and CustomerUpdated events.

A software design approach that connects implementation to an evolving domain model. CQRS is often applied within the context of DDD's tactical patterns.

• Bounded Context: CQRS is frequently applied at the boundary of a Bounded Context, separating the complex, transactional internal model from various external read models.
• Aggregates: The Command model is typically designed around DDD Aggregates, which enforce invariants and produce domain events.
• Ubiquitous Language: The separation encourages defining clear commands (intent) and query models (reporting needs) using the domain's language.

The messaging infrastructure that enables the decoupling inherent in CQRS and Event Sourcing architectures.

• Command Bus: Routes Command objects (e.g., PlaceOrderCommand) to the appropriate command handler. May implement middleware for validation, logging, or transaction management.
• Event Bus: Publishes Domain Events (e.g., OrderPlacedEvent) produced by command handlers. Query-side projection services subscribe to these events to update their materialized views.
• Technology: Can be implemented in-process, via a message broker (e.g., Apache Kafka, RabbitMQ), or a cloud-native service bus.