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.<\/p>\n
Although the 1.0-rc1 version doesn\u2019t add a lot of new features to the previous release (0.7), it does represent a major milestone in Axon\u2019s 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.<\/p>\n
<\/p>\n
Command Query Responsibility Segregation (CQRS) is an architectural pattern that makes a clear distinction between command processing -telling an application what to do- and query execution -which provides insight in the state of the application. This very simple separation of components opens up a large number of interesting possibilities, such as scalability and extensibility. But even if you never expect to need to scale, the basic pattern of CQRS can help tremendously.<\/p>\n
Axon Framework helps build scalable, extensible and maintainable applications by supporting developers apply the CQRS architectural pattern. It does so by providing implementations of the most important building blocks, such as aggregates, repositories and event busses (the dispatching mechanism for events). Furthermore, Axon provides annotation support, which allows you to build aggregates and event listeners without tying your code to Axon specific logic. This allows you to focus on your business logic, instead of the plumbing, and helps to test your code in isolation.<\/p>\n
Similar to asynchronous event handling for event listeners, Sagas can also be invoked asynchronously from the dispatching process. All that is required is the configuration of an (asynchronous) Executor on the SagaManager. It will make sure each Saga processes the events in the order they arrive, one at a time. Multiple saga instances will execute concurrently if the provided Executor allows that.<\/p>\n
In some cases, it might be valuable to keep both the state of aggregates as well as the generated events. The hybrid repository does exactly that. It append newly generated events to the event store, while reading the current state from a relational model. This could speed up the loading of aggregates and removes the need for upcasters. Until you need to read in old events, of course.<\/p>\n
In geographically larger systems, it might be valuable to keep information about time zones in the events. The previously used LocalDateTime does not contain that information. Now, all events use a DateTime instead. This change is completely backwards compatible if you are using the XStreamEventSerializer in your event store.<\/p>\n
Besides these major changes, there is a number of smaller changes that are worth mentioning.<\/p>\n
All dependencies on Spring have been removed, with the exception of the Spring specific configuration options, of course. This means that, if you don’t use any of the Spring config options, you don’t need Spring on your classpath anymore.<\/p>\n
Test fixtures are configured to fail when two events are generated with the same sequence number. This allows tests to fail when an aggregate is accidentally created, instead of modified, for example.<\/p>\n
The JPA Event Store will do a batched fetch from the database when it is reconstructing an aggregate from a large number of events. This will reduce memory consumption, with the penalty reconnecting to the database. The size of the batches is configurable.<\/p>\n
The locking repository now uses Pessimistic Locking by default. Only the pessimistic lock can guarantee that events are dispatched in exactly the same order as they are generated by the aggregate.<\/p>\n
The only API change in the 1.0-rc1 version is the timestamp of the event. If you recompile your project using 1.0-rc1, you might get compilation errors, as the type was changed from LocalDateTime to DateTime (both joda time classes). Migrating these types in your codebase is safe and easy to do. The only difference is that DateTime contains an explicit time zone (which defaults to the server time zone), while LocalDateTime always assumes the server time zone.<\/p>\n
The format of the abstract aggregate root classes in Axon has changed. This means that, when upgrading from previous versions, the snapshot events should be cleared from the event store before launching the application on the new version. If you build custom snapshot events, you do not have to do this. The API of the aggregates hasn’t changed.<\/p>\n
If you have questions or doubts about migrating or anything else, don\u2019t hesitate to send a message to the Axon mailing list (axonframework@googlegroups.com, registration required: www.axonframework.org\/group). The community behind Axon is growing, so if I\u2019m not there to answer your question quickly, someone else is likely to be.<\/p>\n
If you have questions or doubts about migrating or anything else, don\u2019t hesitate to send a message to the Axon mailing list (axonframework@googlegroups.com<\/a>, registration required:www.axonframework.org\/group<\/a>). The community behind Axon is growing, so if I\u2019m not there to answer your question quickly, someone else is likely to be.<\/p>\n If you need hands-on help, don\u2019t hesitate to contact JTeam<\/a> about support and consulting.<\/p>\n You can find more information about Axon Framework on www.axonframework.org<\/a>. Documentation is available online<\/a> (html) and in the downloads section<\/a>. There is also a introductory workshop on CQRS and Axon<\/a>.<\/p>\nMore information<\/h4>\n