More test fixtures

Testing is obviously very important. Axon already has [...]]]> Recently, I released Axon Framework 1.0. Instead of it being an opportunity to take a small break, things have gone into a higher gear instead. In this article, I give a sneak preview of what’s coming up in and around Axon Framework.

More test fixtures

Testing is obviously very important. Axon already has test fixtures to test your command handling components using an easy-to-use given-when-then fixture. But the command handling component is not the only component with potentially complex business logic.

Axon 1.1 will include a similar fixture for testing Sagas. The big difference between a Command Handler and a Saga is that the Saga responds to Events and takes decisions based on them. Quite often, the aspect of time is important. For example, if an invoice is not paid within 30 days, the Saga must send a command to cancel or block an Order. The Saga test fixture allows you to write code like this:

fixture.givenAggregate(orderAggregate).published(new OrderCreatedEvent())
       .andThenAggregate(invoice).published(new InvoiceSentEvent())

       .whenTimeElapses(Duration.standardDays(31))

       .expectDispatchedCommands(new BlockOrderCommand());

This allows you to write human-readable test that define what the behavior should be when certain things happen, or even when they don’t happen.

Work on these fixture is still in progress, but a sneak preview is available in the 1.1-SHAPSHOT version already. Look for the AnnotatedSagaTestFixture class, give it the class you want to test and you are ready to start testing.

Redis event store

Redis is a very nice and full-featured key-value store. Instead of values being plain blobs, Redis allows for lists, sets, maps (called hashes) and even ordered sets. There is also a pub/sub mechanism in place and the API supports the implementation of message queues.

All in all, this makes Redis a very nice candidate for an Event Store implementation. We have already spent some time investigating the API and the level of consistency guarantees that Redis can offer. They match very well with what one would expect from an Event Store. We’ll be spending some more time on it before we decide whether to implement a full-blown Event Store, or not.

Distributed command bus

Scalability is obviously one of the reasons to choose for CQRS. Having components that only work within a single JVM doesn’t really help. I have done a small proof-of-concept with a Distributed version of the Command Bus. So far, the results look really good.

This Command Bus implementation allows commands to be distributed over a cluster of machines for execution. Instead of blindly sending commands to random machines, it uses the Consistent Hashing algorithm to make sure that commands for the same Aggregate will end up on the same machine. If a machine drops, the load is taken over by the remaining machines. You can even –at runtime- add another machine to the cluster and have it take over some of the load. This means you can dynamically adapt your cluster size to meet the needs of that specific moment, without any single-point-of-failure.

The distributed command bus is still in the proof-of-concept phase, but work on the real version will start very soon. I will also build a small application that allows you to see it at work.

2-day “full-immersion” training

Spreading knowledge on CQRS and the Axon Framework has always been on the agenda. In the past few months, I have given suite a number of presentations and 1-day workshops. Although they are nice to do, there is too little time to really dive into the matter. That’s why I have decided to go for a 2-day training.

This two day training is a little different that what you’re used to. Instead of doing a training over 2 days from 9AM to 5PM, this training is 32 hours in a row. Okay, admitted, this includes a few hours of eating and sleeping as well. The training takes place in a hotel in the beautiful “Utrechse Heuvelrug” area in The Netherlands. It’s 2 days, all-in (overnight stay and meals). The idea behind this concept is that we’ll be able to really dive deep into the concepts and get to the bottom of things. So after dinner on the first day, there is time for coding as well as informal chatting at the hotel bar.

The training covers the basic concepts of DDD and CQRS, but also allows you to really get your hands dirty. The first training has been scheduled for June 23rd and 24th 2011. For more information about this training, visit the training page: http://www.jteam.nl/training/workshop/2-day-CQRS-and-Axon-Immersion-Training.html.

Although the 1.0-rc1 version doesn’t add a lot of [...]]]> The Axon Framework 1.0 release is closing in. After over a year of development, all features planned for the 1.0 version are included. With the latest added features, Axon has become a powerful framework that helps developers implementing applications using on a CQRS based architecture.

Although the 1.0-rc1 version doesn’t add a lot of new features to the previous release (0.7), it does represent a major milestone in Axon’s lifecycle. If Axon continues to prove it works as expected in production environments, the final 1.0 release can be expected before summer. Meanwhile, development will start on the remote messaging components required for scalability in larger systems.

Read the entire entry on the JTeam blog.

Test fixtures are now part of the axon-test module. These fixtures allow you to [...]]]> Today, I released version 0.6 of the Axon Framework. 0.6 has many new features and is another step towards full production readiness. There is still some work to do, but first, let’s take a look at what has changed…

Test fixtures are now part of the axon-test module. These fixtures allow you to test your command handling logic based on events and commands. You define these tests in a given-when-then style: given these past events, when I execute this command, I expect these events to occur.

The CommandBus interface now allows for asynchronous command dispatching. Instead of using a return value, a Callback can be given to the command bus if you wish to be notified of the result of command execution.

The repositories make use of a UnitOfWork instance, which keeps track of changed aggregates and generated events. Instead of saving each aggregate separately, the UnitOfWork can be committed, causing changed aggregates to be stored, and events to be dispatched. With the new SimpleUnitOfWorkInterceptor or the SpringTransactionalInterceptor, it is no longer necessary to call repository.save(). In fact, you are discouraged from doing so.

Repositories are now capable of detecting conflicting modifications. When loading an aggregate, you may pass in the expected version of the aggregate. An exception is raised if that version does not match the actual version.

Event sourcing repositories allow for a more advanced way of detecting conflicts. Sometimes, not all concurrent modification are in conflict with each other. One user may very well change the shipping address of an order, while another user is adding items. Other modifications, however, are clearly conflicting, such as one user marking an order as shipped, and another one adding a product. For this purpose, you can register a ConflictResolver with the repository. This conflict resolver can, based on unseen and newly applied events, decide whether the changes made by the second user are accepted.

Axon now provides a mechanism to trigger snapshot creation based on the number of events needed to load to reconstitute an aggregate. When the number of events exceeds a given threshold, a snapshot is created and stored in the Event Store.

The SimpleCommandBus and SimpleEventBus now expose statistics over JMX. Although currently quite limited, the statistics will be improved in the coming versions.

All of these features help making applications with CQRS-based architectures even easier. But we’re not there yet. The coming months, we will try to make it even easier with features like Event versioning, support for aggregates with multiple entities, and whatever comes to mind in Axon’s growing community.

For more information about the Axon Framework, see www.axonframework.org.

Besides some changes to existing building blocks, such as the event bus, which is now much more powerful, the [...]]]> Today, I finalized the 0.5 release of the Axon Framework. There is quite a number of changes since the 0.4 version. The 0.5 version is a major step towards production readiness of the framework.

Besides some changes to existing building blocks, such as the event bus, which is now much more powerful, the 0.5 version also includes some new features.

Read on to find out more.

New features

• Code restructuring. The package structure has been changed to better reflect the different architectural components Axon Framework provides. It should be easier to find the one you’re looking for.
• Command Bus. The command bus is added to Axon. It provides you the ability to explicitly define commands and dispatch them to your command handlers. Furthermore, the command bus provides you the ability to process commands regardless of their type using interceptors. This is useful for, for example, logging, authorization and correlation of incoming commands.
• JPA Event Store. The easiest CQRS configuration is on using full-consistency. That means everything should run within a single transaction. Since transactions over multiple data sources involve a huge performance penalty, Axon provides a JPA Event Store. Its performance is not as good as the FileSystem version, but is does provide transaction support.
• Easy switching between full-consistency and eventual consistency. You can easily choose to process all commands and related events inside a single transaction, or to handle events asynchronously. Choosing for consistency or high-performance is just a matter of configuration. No coding required.
• Per-event listener configuration of asynchronous processing. It is now possible to decide on synchronous vs asynchronous event processing for each event handler individually, just by adding an annotation. If you configure a transaction manager for your event listeners, Axon will process the events in batches and manage the transactions around them.
• Support for rolling snapshots. All event stores will automatically pick up snapshot events. Snapshot events are an important performance booster when aggregates generate a lot of events. Instead of reading all passed events, the event store just needs to read the last snapshot event and the regular events created since the snapshot.
• Transactional Event Processing. Configuring transactions in asynchronous event processing is now a lot easier. 0.5 includes a SpringTransactionManager you can use in combination with Spring’s PlatformTransactionManager.
• Major documentation update. The documentation has been restructured to make it easier to find what you’re looking for.

Maven Central

Where the 0.4 version required configuration of a repository in your project’s pom.xml, the 0.5 version doesn’t. All required artifacts are available in the maven central repository.

Workshop and professional support

We believe that the 0.5 version of Axon Framework is a major step towards production readiness. Therefore, JTeam has decided to provide professional support for the Axon Framework and organize workshops to get you acquainted with the numerous features and choices involved with CQRS.

The first workshop is planned for Friday May 21st in Amsterdam, The Netherlands. For more information, visit http://www.jteam.nl/training/workshop/cqrs-axon-framework-training-workshop.html.

Getting started

Want to get started? Visit www.axonframework.org and download the reference guide. That should contain enough information to get you started. If you still have questions, drop me a message.

In this post, I describe some CQRS event [...]]]> Command-Query Responsibility Segregation (CQRS) is slowly but steadily gaining ground as an architecture that helps developers to develop scalable, extensible and maintainable applications. Events play a major role in this architecture, and the way you design these events greatly influence the extensibility of your application.

In this post, I describe some CQRS event basics and design considerations that help keep your application extensible.

The full post is published on the JTeam blog. Continue to read here: http://blog.jteam.nl/2010/01/27/cqrs-designing-domain-events/

Command Query Responsibility Segregation (CQRS) is an architectural style that makes a clear distinction between commands, which tell an application to do something, and queries, which are requests for information from an application. This distinction comes from the fact that the requirements (and thus also the model) for the execution and validation of [...]]]>  

Command Query Responsibility Segregation (CQRS) is an architectural style that makes a clear distinction between commands, which tell an application to do something, and queries, which are requests for information from an application. This distinction comes from the fact that the requirements (and thus also the model) for the execution and validation of commands are significantly different than those for queries. Events play an important role in the synchronization of application state resulting from executed command.

Applying a CQRS style architecture involves the development of quite a lot of “plumbing” code: event dispatching, asynchronous event processing, transactions, etc. cqrs4j, an Apache 2 licensed open source framework, takes care of all the plumbing for you. Read on to find out how…

A brief introduction to CQRS

As I stated above, CQRS makes a distinction between the model that validates and executes commands and the model that is used for providing state information. This is quite significantly different than how most (web)app applications are build nowadays. In fact, the model used for commands (the box named “Domain” in the image below), does not expose any state, at all. You might wonder, but how do I know what to show in the front end? That comes directly from your data sources using a thin data layer. I’ll explain how the data gets there in a minute.

When a command comes in, it will load an aggregate from the repository and execute certain operations on it. As a result of these operations, the aggregate produces events, which are picked up for storage by the repository and for dispatching by the event bus. The event bus will dispatch each event to all (interested) event handlers. Some of these event handlers will perform actions on other (related) aggregates, some others will update the database tables they manage.

Having handlers update the data in the database means that your tables do not have to be normalized anymore. Instead, CQRS allows you to optimize your tables for the way you want to query them. This makes the data layer processing your queries really simple, and maintainable.

Furthermore, since all state changes are initiated by events, these events become a reliable source for an audit trail. By storing these events, you have an audit trail that you can use to replay the entire application history. Instead of just seeing “current application state” only, you can see all the changes that have led to the current state, providing valuable information trying to find bugs or deal with customer complaints.

The asynchronous and event driven nature of CQRS makes it extremely valuable for complex applications that have different views on the information in the application. Integration with third party systems that need to be notified of certain changes in your application –and vice versa–  is a lot easier if you use an event driven approach. And since event handling is done asynchronously, the application is more responsive and easier to scale.

But as you notice, there is quite a lot of processing and pushing around of events. When you have a customer breathing up your neck, you don’t want to be developing infrastructure code. You would want to be focusing on the business logic, which is quite complex by itself.

cqrs4j

cqrs4j is a Spring-oriented framework that provides the most important building blocks of a CQRS architecture. Creating an aggregate becomes really simple. You don’t have to worry about managing the storage and dispatching of (uncommitted) events. Event sourcing becomes as easy as wiring two beans in your application context.

Annotation support

cqrs4j comes with out-of-the-box annotation support. This makes is really easy to wire event handler methods. cqrs4j can automatically subscribe all your event handlers to the event bus and delegate all relevant events to the appropriate event handlers. Enabling annotation support is as easy as wiring a single bean in your application context.

Spring Integration support

Spring Integration is a framework that allows easy developments of a Messaging systems using the pipes-and-filters architecture. This fits nicely with most of the event dispatching process of CQRS. cqrs4j has support for Spring Integration, which allows you to publish all events as messages on a Spring Integration channel. Sending messages through JMS queues, via email, or through file system storage will only take a few lines of (XML) configuration.

Transaction support

If you update your database tables through incoming events, dealing with them one-by-one in a transaction can become time consuming and take up too much resources of your database. With cqrs4j, you can configure transactions just by setting the @Transactional annotation on your event handlers. You can also configure how many events should be handled in a single transaction.

cqrs4j project page

cqrs4j is an open source project, licensed under the Apache 2 license. Visit the project home page for the latest downloads, documentation and source code at code.google.com/p/cqrs4j.

We welcome your feedback

If you have any requests, remarks or other feedback, please let us know. You can report bugs and improvement requests on the issues page. You can also leave a message via the contact page or by leaving a comment.

Further reading

I have some more CQRS related blog articles coming up, but there are already quite a few around. Here is a few that helped me get started:

• Greg Young @ QCon: Unshackle your domain
• CQRS a la Greg Young
• CQRS – The Domain Events
• CQRS – Domain State
• DDDD – Why I love CQRS