The Axon platform offers an innovative and powerful way of sensibly evolving to event-driven microservices. The platform has roots in the well established CQRS (Command Query Responsibility Segregation) and Event Sourcing architectural patterns as well as the DDD (Doman-Driven Design) concepts.
Evolutionary Event-Driven Microservices
While Axon is rooted in CQRS and Event Sourcing, the platform has a unique value proposition in enabling an innovative evolutionary approach to developing event-driven microservices.
As valuable as the CQRS and Event Sourcing patterns are, in an application that has a high likelihood of remaining a monolith, they are applied in key parts of the application rather than throughout the application. Indeed by default Axon assumes all components are in the same JVM.
However, a key characteristic for Axon is location transparency. If commands, aggregates, command handlers, events, event handlers, queries and query handlers need to be on separate JVMs and typically clustered (perhaps via AxonHub), Axon allows you to make changes only to configuration to make this happen. This is because CQRS and Event Sourcing naturally result in code to be highly decoupled via messages, lending itself to location transparency. What this means is that an Axon application can begin its life as a monolith and be very easily broken up into microservices when needed. Furthermore, the Axon command, event and query buses that facilitate communication can be completely remote and asynchronous just by switching configuration. This asynchronous, event-driven approach to microservices is more loosely coupled, flexible, reliable and scalable as compared with synchronous, typically REST centric approaches to microservices. As long as a majority of the application is developed using CQRS, Event Sourcing and Axon, they can be broken up into arbitrary parts at will, resulting in the finest grain microservices possible if desired (for example to maximize scalability and minimize deployment time for each microservice). Each aggregate entity can even reside in its own isolated microservice and communicate through commands and events.
CQS and Microservices
Implementing CQRS and Event Sourcing throughout the application to maximize evolutionary event-driven microservices flexibility may not be an option for many teams. The approach requires a certain amount of skill, discipline and initial investment. Indeed many teams may have already made the decision to implement microservices and aware of where their service boundaries or DDD bounded context lies. Indeed such applications may not even have a significant need for Event Sourcing.
Such teams can still take advantage of the Axon platform to realize the benefits of loosely-coupled, asynchronous, event-driven microservices. This technique applies the CQS (Command-Query Separation) pattern to microservices (as you may guess from the naming, the CQRS and CQS patterns share origins). The CQS pattern observes that most application invocations can be categorized as commands or queries, but not both. Following this pattern, all interactions between microservices (perhaps deployed as separate DDD bounded contexts) can be modeled as commands, queries and events managed by the Axon Platform. Axon does not require the use of CQRS or Event Sourcing to implement microservices communication in this way. Internally each microservice is free to implement largely a CRUD style, non-CQRS application model using non event-sourced persistence. Modeling the messages between microservices using CQS still provides better semantic meaning, clarity and simplicity.
Integration Events, Event Sourcing and Microservices
Some teams may have chosen to adopt synchronous, REST based microservices as their principal paradigm. There are important cases where such teams can use the Axon Platform to synchronize distributed data using Integration Events and Event Sourcing.
A common problem in microservices is key data owned by a single microservice but shared across multiple microservices in one form or the other. A highly scalable, flexible and reliable way of synchronizing this data is using Event Sourcing, Integration Events, eventual consistency and Axon. In this technique, the microservice that owns the data uses Event Sourcing to store the data as well as notify all other interested microservices of all changes to the data through DDD Integration Events. An Integration Event is effectively a change in state in a single DDD bounded context (or microservice) that other bounded contexts (or microservices) should react to. Event listeners in interested microservices will process the sourced events and update what is effectively internal read models of the data that interests them. This is also a useful technique for incrementally breaking up an existing monolith.
and find out useful news on Axon releases, invitations to AxonIQ events and other news