We are happy to announce that Axon 3.3 has been released. We have got some nice new features for you, and of course we resolved several issues we (and you) have encountered in previous versions.
Probably the most note worthy feature introduction for the framework is the subscription query API. This subscription query API has been added to the QueryBus/QueryGateway, which allows you to subscribe to updates of a given query. Thus instead of periodically checking whether your Query Model has been updated, you can now have a subscription on a given Query Model to receive all its updates. Using this functionality is a two step process, where firstly you will perform the subscription query on the QueryBus/QueryGateway and assign a process to handle the initial result and consecutive updates. Secondly you would add a QueryUpdateEmitter to for example your Query Model updater (e.g. a class with event handlers) which would emit all the changes being made to the Query Model.
Long time users of the framework might be familiar with the EventScheduler API contained in it. As of now you can also leverage a more specific scheduling mechanism dubbed the DeadlineManager. When using the DeadlineManager you can now schedule a DeadlineMessage to be published at a certain point in time. This DeadlineMessage which will be handled within a specific scope, were the scope can either be an Aggregate or Saga instance. To actually handle that DeadlineMessage in an Aggregate or Saga you can add @DeadlineHandler annotated function just as you would add command or event handlers.
Another interesting addition as of 3.3 is the addition of the axon-kafka module. This module provides similar functionality as the axon-amqp module does, but instead of using AMQP it uses Kafka to send / receive events from one to another. The other main difference between axon-amqp and axon-kafka is that Kafka provides a streamable solution for consuming your events. This might seem small, but it will allow you to replay an Event Processor which receives its events from a Kafka source, whilst AMQP does not.
We have also done some smaller improvements, like:
- An Aggregate Root can now instantiate another Aggregate Root, which typically follows naturally from any given Domain.
- CommandHandlerInterceptors can now be defined within an Aggregate itself.
- The TrackingToken of a TrackingEventProcessor can be initialized at a certain point in time.
- The EventHandlingConfiguration has been deprecated in favor of the EventProcessorRegistry. This was required to for example configure several Sagas to be handled by one Event Processor.
To check out a complete list of all we have added, improved and fixed, check out the release notes here.