Conceptually, an event store is very simple. For persisting an aggregate, all new state change events need to be stored. When loading an aggregate back into memory, each event is replayed against your domain so that the aggregate is put back into the right state. The original interface of the EventStore reflected this in a very straightforward manner:

public interface EventStore<EventType> {
    void storeEvents(UUID aggregateId, List<EventType> events);
    List<EventType> loadEvents(UUID aggregateId);
}

The storeEvents method handles both storing the first events for a newly persisted aggregate as well as adding additional events after further transactions. The loadEvents method simply returns all events stored for the aggregate.

This interface works pretty well as a starting point, but is hard to extend to support some features you will likely need in a real system:

• Polymorphism
• Snapshots
• Versioning and conflict resolution

So for the training example the interface was modified to support polymorphism and versioning:

public interface EventStore<EventType> {
    void storeEventSource(EventSource<EventType> source);
    T loadEventSource(Class<T> expectedType, UUID eventSourceId);
    T loadEventSource(Class<T> expectedType, VersionedId eventSourceId);
}

The EventSource is a new interface that must be implemented by your aggregate root:

public interface EventSource<EventType> {
    VersionedId getVersionedId();
    List<EventType> getUnsavedEvents();
    void loadFromHistory(List<EventType> history);
}

The getVersionedId and getUnsavedEvents methods are called when persisting an aggregate. When loading the aggregate the event store instantiates your aggregate with its current id and version and invokes loadFromHistory.

Although this change added support for polymorphism and versioning it is not a very clean interface:

• The aggregate root must implement the EventSource interface, coupling it to the event store
• The EventSource interface is used both as a source and a sink
• The event store instantiates your aggregate, passing in the VersionedId. So your aggregate root must also have a one-argument constructor

Finally, the implementation of the event store was not very clean either, mixing JDBC, reflection code, and version management.

So last weekend I decided to start with a clean slate and re-implement the event store. Now one of my favorite ways to design and implement an API is to start with unit tests and a plain Java implementation, without trying to tackle the actual JDBC code at the same time. Maps and Lists are great for storing data while doing exploring the various designs. Furthermore, the tests are completely reusable when it is time to write the actual JDBC implementation.

Here’s one of the first test cases:

@Test
public void should_create_event_stream_with_initial_version_and_events() {
    FakeEventSource source = new FakeEventSource("type", 0, T1, EVENTS);
    subject.createEventStream(ID_1, source);

    FakeEventSink sink = new FakeEventSink("type", 0, T1, EVENTS);
    subject.loadEventsFromLatestStreamVersion(ID_1, sink);

    sink.verify();
}

As you can see from the test case the roles of event source and event sink have been made explicit. Creation of an event stream is now also separate from storing additional events into an existing event stream. Furthermore, the aggregate no longer needs to implement these interfaces. The Repository implementation will need to do the mapping between your domain classes and the event store. Here are the new event store interfaces with various methods added to support loading historical data:

public interface EventSource<EventType> {
    String getType();
    long getVersion();
    long getTimestamp();
    List<EventType> getEvents();
}

public interface EventSink<EventType> {
    void setType(String type);
    void setVersion(long version);
    void setTimestamp(long timestamp);
    void setEvents(List<EventType> events);
}

public interface EventStore<EventType> {
    void createEventStream(UUID streamId, EventSource<EventType> source);
    void storeEventsIntoStream(UUID streamId, long expectedVersion, EventSource<EventType> source);

    void loadEventsFromLatestStreamVersion(UUID streamId, EventSink<EventType> sink);
    void loadEventsFromExpectedStreamVersion(UUID streamId, long expectedVersion, EventSink<EventType> sink);

    void loadEventsFromStreamUptoVersion(UUID streamId, long version, EventSink<EventType> sink);
    void loadEventsFromStreamUptoTimestamp(UUID streamId, long timestamp, EventSink<EventType> sink);
}

As you can see the EventSink and EventSource interfaces are very much opposites and easily extensible with supporting new features like loading from a snapshot or supporting conflict resolution.

Finally, after having a full test suite and an in-memory implementation of the new event store (which took most of the day) adding a new JDBC based implementation was just a couple of hours of work, requiring only minimal changes to the tests and interfaces, mostly related to exception handling. The current JDBC event store implementation is about 250 lines of Java, very modest for a domain persistence mechanism.

However, other interesting things intervened and I never got around to doing this.

But every few months we have a one day internal training course at Xebia Software Development and after Sjors Grijpink and I proposed to give a training on DDD and CQRS we got some time to actually prepare and implement a CQRS example application.

The application is fairly simple (as it should be for a one day training course) but touches on all the major components needed for a full-blown CQRS implementation.

The source code for the training exercises can be found at github. There are three branches:

1. exercise – the code used for doing the training exercises.
2. solution – the same code as above but with the solutions added.
3. master – the main development branch, currently used to implement more advanced features like snapshotters, command-event conflict resolution, historical tracing, etc.

The Xebia ITR CQRS presentation is also available.

All-in-all the training was a success and I think that the basic CQRS principles are the way forward when you need to build enterprise applications with a complicated domain logic or strong auditing or historical tracing requirements.

The five posters we presented were:

• Scala by Arjan Blokzijl – a quick overview of the main features and characteristics of the Scala programming language
• @Composite by Andrew Phillips – making Java annotations more reusable
• FitNesse and VMWare by Robert van Loghem – combining FitNesse and VMware to decrease installation and configuration of the system under test
• Domain-Driven Design and Command-Query Separation by Erik Rozendaal – separating the domain model from query and reporting concerns
• GIT by Arjan Molenaar – an overview of git – a fast version control system created by Linus Torvalds

All-in-all these poster presentations were successful and a lot of fun to do. The discussions were much more interactive than regular meeting sessions. This allowed the participants to quickly gain an understanding of the presented topics as well as allowing them to go into specific details, pros, and cons. Another big plus is that we received immediate feedback on the applicability of the presented topics.

At his presentation, Greg quickly pointed out some of the problems with traditional enterprise application architecture, such as JEE. This architecture usually consists of an “object-oriented” domain model encapsulated inside a procedural service layer, persisted in a relational database, flattened out on a data entry screen by the UI layer, and crunched daily into management reports by some reporting tool. With so many masters, it’s no wonder that the domain model becomes anemic and the application is hard to scale.

Greg needed something better. Something that is able to sustain 10,000 transactions per second, supports bullet-proof auditing, and has a rich domain model to implement complicated financial business logic.

His key insight is that the application should explicitly model state transition commands as classes and strictly split these commands from queries on the application interface level. So any kind of client UI or report will use the query interface of the application to get its needed data using a thin DTO layer while updates uses the command interface. These command objects also support the audit requirements and drive the domain model.

Now the domain model only supports a single concern: validating and executing commands. No longer does the domain model need to support querying, so your objects no longer need lots of getters and setters: Tell, don’t ask! In addition to this, the domain model can now be stored using a data store optimized for updates, such as Hypertable or CouchDB.

For the query interface a read-optimized database can be used, updated by events from the domain model. You can easily denormalize this database without reducing the efficiency of writes on your domain model. Furthermore, it is now possible to easily replicate this read-only store for extremely high scalability.

In the next few weeks I’ll investigate the practical implications of this approach, the needed infrastructure to get this working, and the possible applications that could benefit.

Looking back, the last major change of Java language was with the release of Java 5 in 2004. Java 7 will bring changes, but is late. The advantage is stability, but the price to pay is that the brightest minds in the industry start to leave Java behind.

A prime example is closures. A lot of Java code is simple boilerplate code, like managing your JDBC resources just to execute a simple query, iterating over a collections just for some transformation or filtering, implementing builders to ensure complicated classes are initialized correctly, implementing GUI event handlers, operations inside parallel processing frameworks, etc. Closures allow you to easily reuse control flow patterns, reducing or eliminating this kind of error prone code.

A language cannot remain static and still have a thriving community. The effects can already be seen on a conference like QCon, where Java has been left behind for greener pastures by many speakers and attendants.

The first part discussed the threat of agile development to the role of traditional architects and the distrust between developers and architects. Although many of the Ivory Tower Architect stereotypes may contain a grain of truth, the cause is often not the architects themselves. Many organizations put architects in a position that makes it hard or impossible to be successful:

• Goals like achieving 30% reuse – how to measure and promote this?
• Architects are not allowed to write code – so how can the architects keep up with the latest technology?
• Architects are often outnumbered by developers 30 to 1 or more – this leaves no time for being involved with projects or mentoring of the developers.

Traditionally this leaves the architects with very few options, like specifying a reference architecture and requiring all projects to adhere to it, even when the architecture is not a good fit for the specific project. Not only does this clash with agile development, but agile development may even threaten this model. It is not surprising that this causes distrust between architects and agile teams.

But this adversarial relationship is not necessary. The second part of the presentation addressed how agile development allows the architects to be successful:

• Visibility in progress by delivering working software every iteration, allowing the architect to be involved and react.
• Up-to-date specifications of functionality through automated tests.
• Extracting reusable components from working code, instead of trying to build reusable components up-front that may never be used. “After the fact” instead of “design up front” reuse.

So how can you involve the architects into the agile development process? By treating the architects as another stakeholder, just like the regular customer. The architectural requirements will need to be prioritized just like any other requirement. And requirements like “the system must be maintainable” will have to become specific and implementable, making the work of the architects more concrete and valuable.