Gridshore » DDD

Axon Framework 0.6 released

Allard — Sun, 08 Aug 2010 17:53:45 +0000

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.

Axon Framework 0.5 released

Allard — Sat, 24 Apr 2010 15:27:59 +0000

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.

CQRS – Designing domain events

Allard — Wed, 27 Jan 2010 11:33:31 +0000

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/

CQRS made easy with cqrs4j

Allard — Mon, 21 Dec 2009 08:37:00 +0000

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.

SOA and the domain: how new technology should not blind you to old wisdom

Ben — Wed, 02 Apr 2008 21:50:59 +0000

A couple of things happened to me over the past few days as I was taking on a new role within a new project that caused me to ponder a bit about the role of domains and domain driven development (DDD) within the drive towards service oriented architectures (SOA). The result of these ponderings was, as it often is in my case, that the more we think things change, the more they stay the same. And the more we think we learn, the more we find we already knew what we have learned.

The first thing…

The first thing that happened is that I moved to my new project and found myself in a discussion about dealing with the consequences of earlier choices about how to deal with the overall application domain in the context of an application that will exist of a number of different, independent components composed using Web Services. As you will have already guessed, my new project is trying to implement a SOA (with service components that will later be part of a larger SOA).

The situation the project was in had developed from an attempt at implementing SOA by the book (in a somewhat reversed style). As we all know by now, the main tenet of SOA is that it allows you to take specialised components that deal with a single task well and combine them into larger services or applications with business meaning. Of course one might also reason (as my new project had done) that this means that you can take the specification of a new application and decompose it into functionally separate and specialised blocks. Implement these separately and compose them using web services et voilá: instant SOA.

To ensure that the different components would fit together (especially when communicating over the wire, but in general as well) it had been decided that all XML schemata and all implementation classes would be derived from the overall, conceptual domain model. Specifically, the model would be captured in a single set of implementation classes and shared across all the different components. The same model would be reflected in the XML messages passed between components.

When I arrived the project had become embroiled in problems related to tight coupling of its independent components. On the design side the use of a single domain meant that each component had to compromise in how well elements from the domain were suited to its purpose. On the implementation side, using a single domain package in all components meant that every change in any one component meant a rebuild and redeployment of all components.

The second thing

The second thing that happened was a discussion I had with a colleague about an MSN message he had written. He had used the word “enthousiasts”, after which I chided him about speaking “Nenglish” (English mucked up with Dutch influence). A search through a diary proved that he was correct, enthousiasts is perfectly good English — in British spelling.

It took a little time for it to sink in that, even though he had misspelled the word in my eyes, I still knew what he was talking about. Even though it wasn’t my spelling, the concept of what he was saying had rung a bell in my head. One might model the situation like so:

What is illustrated by this diagram is that two people can speak different dialects of the same language yet share the meaning of words and concepts. They each have a language of their own, yet somehow both also “know” a second language that both share, speak perfectly and can use to communicate relatively flawlessly.

So what does this teach us about SOA?

The two situations described above teach us an important lesson about the role of domains and DDD when implementing a SOA: each component within a SOA has to deal with multiple domains, should be aware of this and should be allowed to do so.

A typical component in a SOA has a number of connections to components in the outside world. This is because a typical component in a proper SOA does a single task and does this well and is therefore of interest to other components within the same SOA. And of course, the component itself might use other components to complete its task, for the same reason. So let us say that a given component offers N services to the outside world and references M other components. I then claim that the component has to deal with N + M + 1 different (but obviously related) domains, N + M + 1 separate languages. N languages that it shares with its clients, M languages that it shares with its referenced components and one more: its internal domain that it uses to do its job so well. In practice of course not all these languages will be distinct (or at least not completely); there may be overlap or shared communication languages. But conceptually N + M + 1 is the number and this fact should not be feared but rather respected. After all, it is this fact that allows components within a SOA both to be efficient and proficient at their own tasks, yet interoperate with other components at the same time.

Developing a single component within a SOA is all about performing a single task and doing that right, then passing the results on in a usable form. In that respect SOA is just a reinvention of the Unix command line tools. Tools like sed, grep, ls and so on don’t all do the world — they do one thing, do it well and allow their results to be piped in to the next tool in the chain. At the same time, no single tool cares about how the previous tool reached the results it did — just that it did. SOA components are much the same.

It is at this junction that we reach DDD. Each SOA component deals with a single, solitary, complex problem. A problem no other component in the same SOA deals with, nor should. DDD teaches us that complex problems should be based on a domain suited to solving that problem and that that domain should be the primary focus of the component. The component should care about how to solve its own problem well; it should not care about what anybody else is doing beyond the extent of getting needed data and passing it on.

Moreover, DDD teaches us that the domain is divided into a number of different pieces. One of these pieces is focussed strictly on solving the actual problem (this is called the core domain), the other pieces are ancillary to accomplishing the task at hand. Some ancillary pieces might focus on communication with other components whose focus is on other problems. Eric Evans refers to this as repositories or in the extreme anticorruption layers (which prevent one model from leaking into another). It is therefore not at all unusual to see a structure within SOA components as illustrated on the right.

The figure on the right illustrates a SOA component, which offers a business service. This service is accomplished by leveraging a specialised domain model, tailored to the problem at hand. At the same time the component does not live in isolation — it is published to other components and connected to underlying services. But the publishing and the connecting are not part of the component’s core domain; these task are undertaken by ancillary components. And a prime task of these ancillary components is to translate between the component’s own domain model and that used to communicate with other components. Let there be no mistake, these are anticorruption layers in the literal sense of the term: they allow component to be specialised and service-specific domains to exist in isolation without being corrupted by the needs of the domain of every other component in the same SOA.

Of course that does not mean that each domain of each component within a SOA is completely unrelated to all others. There will by necessity be overlap in the concepts that are captured by two communicating components. However, in order to allow for an optimal solution to the individual problem addressed by a component it is necessary for that component to have full freedom in how it embeds that shared concept within its own domain and how much weight it carries within that internal domain (one man’s priceless is another man’s worthless after all).

At the same time a SOA component is completely worthless if it cannot communicate. It must therefore be able to deal with the communication domains that it shares with other components (the first step in moving from the domain of one component to the domain of the next). The techniques that DDD teaches us for dealing with communicating domains are therefore essential to building SOA components that strike the right balance between interoperability and optimized problem solving.

And so, once again, we see that moving to a new technology and a ”new” architecture is no reason to forget everything we have learned. In fact, if anything, it shows the importance of recognising “new” ideas for what they are. If you know which wheel is being reinvented, you know which tools you must reinvent to make it run properly as well.

Reference: Domain Driven Design: Tackling Complexity in the Heart of Software