Domain events are a fundamental concept in event-driven architectures, capturing significant occurrences within a system. Event streaming architectures typically separate responsibilities into command-side and query-side components, each handling events differently to optimise for their specific use cases.
CQRS
Command Query Responsibility Segregation (CQRS) is a design pattern that separates a system’s read and write operations into distinct models. This separation optimises the handling of commands (writes) and queries (reads), improving scalability and performance. In an event streaming architecture, CQRS is often implemented by dividing the system into command-side and query-side components.
Command-Side Event Streaming
Command-side event streaming captures and records all state-changing operations within a system. Each command execution generates events that represent immutable facts about what has occurred.
Key Characteristics
- Immutability
Events cannot be modified once recorded, ensuring an accurate historical audit trail. - Ordering
Events are stored in the sequence they occurred, maintaining causal relationships. - Completeness
All state changes are captured, enabling full reconstruction of the entire system state at any point in time.
Primary Responsibilities
- Recording domain events triggered by command execution.
- Persisting events to an event store for durability.
- Publishing events to subscribers for downstream processing.
- Maintaining event versioning for schema evolution.
Benefits
- Complete audit trail of all system modifications.
- Ability to rebuild the entire state through event replay.
- Decoupling of command processing from side effects.
- Foundation for temporal queries and point-in-time state reconstruction.
Query-Side Event Streaming
Query-side event streaming subscribes to domain events and maintains read-optimised data models tailored to specific query requirements. These models are built by processing events from the event store, enabling efficient retrieval without affecting command-side operations.
Figure 1 depicts this interaction.
Figure 1: Query-Side Event Streaming in CQRS Architecture
This diagram illustrates the flow of a query in a CQRS architecture where the query-side event handler subscribes to an event stream, processes events, and updates the read model accordingly. The user sends queries to the read model, which fetches data indirectly via the query handler, which listens to the event stream for updates.
The query handler is responsible for processing events from the event stream and updating the read model, ensuring that users receive up-to-date information when they send queries.
This architecture allows separation of concerns, where the command side can focus on handling commands and the query side on handling queries, improving scalability and performance.
Key Characteristics
- Optimised for Reading
Data structures are denormalised and indexed to support fast queries. - Eventual Consistency
Query models become consistent with the command side after all events have been processed. - Stateless Processing
Event handlers transform events into query-friendly formats without modifying the source events. - Multiple Projections
Different projections can be derived from the same events for various use cases.
Primary Responsibilities
- Subscribing to published domain events.
- Transforming events into optimised query models.
- Maintaining denormalised data structures for efficient retrieval.
- Handling projection rebuilding and schema migrations.
Benefits
- Separation of read and write models improves scalability.
- Queries execute rapidly against pre-built models.
- Support for multiple domain views without duplicating business logic.
- Flexible model evolution independent of the command side.
How They Work Together
In an event streaming architecture, the command-side and query-side components operate in tandem to provide a robust system for handling both state changes and data retrieval. When a command is executed, it generates domain events that the command-side event store records. These events are then published to subscribers, including the query-side components. The query-side event handlers process these events to update their read-optimised models, ensuring that queries can be served efficiently without affecting command processing performance. This separation allows for independent scaling, evolution, and optimisation of both sides of the architecture.
Figure 2 sums it up.
Figure 2: Event Streaming in CQRS Architecture
This diagram illustrates the flow of events in a CQRS architecture with event streaming. The command handler processes commands and updates the query model, which is denormalised for efficient querying. The query model also updates indexes and notifies subscribers of changes. Clients can send query requests to the query model and receive results based on the updated data. The separation of command and query responsibilities allows for independent scaling, evolution, and optimisation of both sides of the architecture.
Versioning and Schema Evolution
Both command-side and query-side event streaming must handle event versioning and schema evolution to accommodate evolving requirements; nothing stays the same. It may not be possible or convenient to update all components of a system and its sub-systems simultaneously. Therefore, strategies for managing changes to event schemas over time are essential to maintain system integrity and compatibility. Strategies include:
- Versioned Events
Including version information in event schemas to manage changes over time. - Upcasters
Transforming older event versions to the latest schema during processing. - Schema Registries
Centralised repositories for managing event schemas and their versions.
Conclusion
Event streaming architectures effectively separate command-side and query-side responsibilities, enabling systems to handle state changes and data retrieval efficiently. By leveraging domain events, these architectures provide a robust foundation for building scalable, maintainable, and responsive applications.
When implementing event streaming, it is crucial to consider factors such as event versioning, schema evolution, and the specific requirements of both command and query operations. At its core, event streaming involves capturing, storing, and processing domain events to facilitate a clear separation of concerns between command and query functionality. It consists of publishing events from the command side and subscribing to them on the query side, enabling each component to operate independently while maintaining overall system coherence.