Part 4 - From Coordination Acts to Event-Driven Systems

This fourth installment in our series delves into how CQRS and Event Sourcing patterns integrate with DEMO’s transactional model to create scalable, responsive enterprise solutions. By linking coordination acts to real-time event processing, we uncover new ways to drive flexibility and efficiency in business transactions. This series continues to provide insights every Monday and Thursday.

While we have already established how coordination acts in the Complete Transaction Pattern (CTP) can be interpreted as business events in an event-driven architecture, it’s crucial to explore how these concepts integrate into modern enterprise systems, particularly through the Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES) architectural patterns. These patterns help bridge the structured nature of DEMO’s transactional model with the dynamic, real-time capabilities of event-driven systems, ensuring scalable and responsive enterprise solutions.

Introducing CQRS and Event Sourcing

The CQRS pattern [MF 2012] separates the responsibility of handling commands (changes to the system) from queries (read operations), allowing for greater flexibility, scalability, and performance optimization. In a CQRS architecture, the system is divided into:

• Command Side: Responsible for handling commands that mutate the state of the system. Commands correspond to the coordination acts we’ve already discussed, such as a Request Act (e.g., a customer placing an order) or a Promise Act (e.g., an executor confirming an order).
• Query Side: Dedicated to serving queries by providing the current state of the system. This part is optimized for reading data, and used to present information from the Fact Model to support coordination acts.

Event Sourcing (ES) [MF, 2005] complements CQRS by ensuring that every change to the system’s state is captured as an event, rather than overwriting data. Instead of storing just the current state of a transaction, the entire sequence of events is saved, allowing the system to “replay” events and rebuild the state as needed. This approach aligns with CTP’s revocation capability, by maintaining a comprehensive history of all changes, allowing for the accurate replay and adjustment of transactions when acts are revoked. This ensures that the system’s state is consistently updated and reflective of any modifications or cancellations during the execution of the end-to-end business process.

Example: Applying CQRS/ES in an E-commerce Platform

Let’s revisit the earlier example of an e-commerce platform transitioning to a microservices architecture. In a CQRS/ES pattern:

• Command: When a customer places an order (Request Act), this command is handled on the write side of the system. If the product is available, the system executes a Promise Act, committing to the delivery of the product. This command updates the event log by creating an OrderPromised event, capturing the promise to deliver.
• Event Sourcing: Each of these acts (-OrderRequested, OrderPromised, OrderDeclared-) are stored as events. If a Decline Act occurs (e.g., due to lack of stock), this too is recorded as an event. These events can be used to reconstruct the entire transaction history, allowing for better traceability and auditability, which is a key feature of event sourcing.
• Query: On the query side, users can retrieve the current state of their order by querying a read-optimized view. For example, the system might provide a view of pending orders for the fulfillment team or an order status dashboard for the customer. These views are based on the sequence of events stored in the event log, allowing users to see real-time information about the status of each order.

This separation of command and query functions ensures the system remains performant and scalable, even as the volume of transactions increases. Additionally, it allows for real-time feedback to users, enhancing the overall user experience, as discussed in the next chapter about Event Modeling and View Modeling.

Transitioning to Event and View Modeling with DEMO Aspect Models

As we move forward to explore Event Modeling and View Modeling, the CQRS/ES architecture provides a clear framework for mapping DEMO’s aspect models into the enterprise solution architecture:

• Commands align with the coordination acts described in the Cooperation Model (CM) and Action Model (AM), providing a blueprint for the workflow that governs each transaction.
• Queries and Views are closely linked to the Fact Model (FM), which defines how the outcomes of coordination acts are recorded and presented. This model is essential for view modeling, where we ensure that stakeholders have access to the information they need based on their role in the business process.

By leveraging CQRS and Event Sourcing, enterprises can ensure that the underlying architecture not only supports complex transactional processes but also enables agility, scalability, and real-time responsiveness.

Discover how this journey began in Part 1 – Introduction and Overview. Explore what lies ahead in Part 5 – Event Modeling and View Modeling with DEMO’s aspect models.

Unlock Exclusive Insights!

If you’re eager to dive deeper into the methodologies and strategies discussed in this series, we invite you to request a copy of the comprehensive whitepaper, containing all the articles in this series. To get your copy, simply fill out our form here. Don’t miss out on the opportunity to enhance your understanding and transform your organization!

References

[MF 2012] Fowler, Martin (2012). CQRS. https://martinfowler.com/bliki/CQRS.html last visit 18oct2024 ??

[MF 2005] Fowler, Martin (2005). Event Sourcing. https://martinfowler.com/eaaDev/EventSourcing.html last visit 18oct2024 ??