Erik Rozendaal

Event Sourcing and State Derivation

2010-10-19T18:47:00.012+02:00

One of the most interesting aspects of the CQRS architecture is the ability to use event sourcing within your business applications. Representing all state changes as domain events has various benefits, not in the least being able to look back upon historical data to derive new information.

However, although historical information is nice, every system must also know its current state. Accessing the current state in traditional applications is just a database lookup. Can we do this in an event-based systems without adding a lot of complexity?

In my Java CQRS example application I used the following pattern:

 public class Lottery {  
   private final Set<LotteryTicket> tickets = new HashSet<LotteryTicket>();  
   private double ticketPrice;  
   private double prizeAmount;  
   private void onLotteryCreatedEvent(LotteryCreatedEvent event) {  
     this.ticketPrice = event.getTicketPrice();  
     this.prizeAmount = event.getPrizeAmount();  
   }  
   private void onTicketPurchasedEvent(LotteryTicketPurchasedEvent event) {  
     tickets.add(new LotteryTicket(aggregate, event.getTicketNumber(), event.getCustomerId().getId()));  
   }  
 }

So for each type of event a method is added that updates the current state. Some framework magic (involving reflection and other dark arts) take care of taking the event stream and invoking the right method on the Lottery instance. This approach works quite well for simple cases, but the event handling code seems hard to reuse in other contexts, especially when multiple different events update the same state (not an issue in this example). Something like the one table per view pattern could become quite unwieldy this way.

Another problem is that this approach was only used by the core domain. The reporting side implements similar logic using plain old JDBC, so the UI can easily show the current state of the system to the user.

Reactive Programming

Fortunately, some interesting new frameworks have started to come out that explicitely deal with event based applications. One of these is the Reactive Extensions (RX) framework from Microsoft. Note that I've not been the only one to see that RX could be beneficial to CQRS applications.

Since I'm used to the Java VM and I also want to learn more about Scala and RX I took some of the concepts of RX and reimplemented these in Scala over the course of a weekend, mainly to find out how reactive programming can help when dealing with event-driven systems. In Scala the example becomes:

 class Lottery extends Subject[LotteryEvent] {  
   val prizeAmount = collect { case event: LotteryCreated => event.prizeAmount }.first  
   val ticketPrize = collect { case event: LotteryCreated => event.ticketPrize }.first  
   val tickets = collect { case event: TicketPurchased => new LotteryTicket(this, event.customerId, event.ticketNumber) }  
 }

Here Lottery is a Subject[LotteryEvent], meaning that it can observe a stream of LotteryEvents and then republish these to other subscribers. To determine the Lottery's current prizeAmount, the collect method is used to subscribe to this Lottery instance and filter on LotteryCreated events. The first such event determines the prizeAmount. The ticketPrize is similarly defined.

The Lottery's tickets contains the information from all the TicketPurchased events.

Although the amount of code doesn't differ much, the definitions of the reactive versions can easily be reused in other contexts (with a little refactoring) and doesn't require any reflection. Furthermore, the reactive framework contains many more combinators that allow you to handle multiple event streams, corrolate events, etc.

Conclusion

The reactive version may not be a clear win, but it looks interesting enough to investigate further. Especially interesting will be extending this to more complex scenarios as well as persisting these derived states to a database for quick querying.

And finally, a word of caution: trivial examples like this can be very misleading.

CQRS presentation for the Dutch DDD User Group is now available

2010-04-24T12:37:00.011+02:00

Monday, March 1st 2010 I gave a presentation on Command-Query Responsibility Segregation (CQRS) at the Dutch DDD User Group. There were about two or three times more people there compared to the previous meetup, probably due to the presence of Greg Young, who provided many useful insights during the discussions.

The main part was recorded and is now available on YouTube. The slides are also available. For ease of viewing (and to work around YouTube's 10 minute limit) the presentation has been split up into the following parts:

CQRS: The Domain - Design Options

2009-12-14T20:37:00.015+01:00

When using the Command-Query Responsibility Segregation architecture the domain is solely responsible for executing update behavior.

Removing the query responsibility from your domain code enables new ways of designing and implementing the domain. The only additional requirement is that your domain must raise domain events so that the query database (and other interested parties) can be kept up-to-date.

Object-Relational Mapping

Just as with a traditional three-tier architecture the domain can be persisted using an ORM tool like (n)Hibernate, JPA, etc. Since the domain no longer needs to support query operations the relationships and mappings are likely to be simpler. This will reduce the impact of the ORM tool on your domain, but won't eliminate it entirely.

Domain events must also be raised. This is most easily done with some simple infrastructure and accessed simply through a static method: DomainEvents.raise(event). This is the approach used by Udi Dahan and is explained by his Domain Events - Salvation article.

This approach has the advantage that you can reuse your knowledge of an ORM managed domain model and may also be useful when migrating from a three-tier architecture to a CQRS architecture.

The main disadvantage of this approach is that there is no guarantee that the state changes persisted by the ORM match the state changes represented by your domain events. Depending on your needs this may or may not be a problem.

Event Sourcing

Another approach is to only persist the events, not the actual domain objects. Since all state changes are represented by events, the state of your domain can be restored by reloading and replaying all applicable events. This is the approach advocated by Greg Young and combines Domain-Driven Design with Event Sourcing. See my blog on the design of the event store for some implementation considerations and there is also an example application using this approach.

With this approach, your Aggregates become event sources and consistency boundaries that can be loaded and stored independently.

Advantages include a domain model free of any ORM mapping and a fully consistent audit log. Events are also guaranteed to be consistent with your domain model, since your domain is loaded using the same events that are send out to the query model.

A disadvantage is that relationships between aggregates can be somewhat harder to manage than with a traditional ORM mapped domain model.

Other Options

When using Event Sourcing the persistence concerns are almost completely taken out of the domain code and moved into infrastructure. This opens up the possibility of using a completely different paradigm whe implementing the domain. One example would be the use of a functional programming language to implement your domain logic.

In this case each command can be represented as a function: f :: [Event] -> [Event]. The input to the function would be the historical events already persisted and the output would be the events representing the results of executing the command. The infrastructure takes care of persisting and publishing the events, leaving the domain functions side-effect free.