In this blog, We will discuss axon framework terminologies and servers we’ll be talking about part one the structure of an axon application but prior to diving into that, we’ll first have a couple of the axon concepts which come into play when you’re working with an axon application. You might want to learn more about like command query responsibility segregation or using commands events and queries as message-driven API DDD event sourcing but also very importantly evolutionary microservice these will all be concepts.
We needs will intend to cover in detail the Axon terminology that the Axon Framework provides to help build applications based on CQRS/DDD and Event Sourcing
A summary of the various terminologies is given below
Query
Axon queries describe a request for information or state. A query can have multiple handlers when it dispatches queries, the client indicates whether he wants a result from one or from all available query handlers.
- Query Processing
- Query Dispatchers
- Query Handlers
- Implementations
- Configuration
Messages
In Axon one of the core concepts is messaging. All communication between components is done by message objects. This gives these components the location transparency needed to be able to scale and distribute the components when necessary.
In the Axon, all communication between components is done with explicit messages, represented by the Message interface. A Message consists of a payload, which is an application-specific that represents the actual functional message, and Meta Data, which is a key-value pair describing the context of the message.
- Message Concept
- Message Correlation
- Message Interceptor
Command
Axon application is associated with Command Messages, accepting from the true source of the outer world.
Axon commands describe an intent to change the application’s state (event state). They are implemented as (preferably read-only) POJOs that are wrapped using one of the CommandMessage interface implementations.
Commands always have exactly one destination. While the sender does not care which component handles the command or where that component resides, it may be interesting to know the outcome of it.
- Modeling
- Command Dispatchers
- Command Handler
- Infrastructure
- Configuration
Event
Event Sourcing is an Axon architectural pattern in which Events are considered the “source of truth”, based on which components are built in their internal state. Events are objects that describe something that has occurred in the axon based-application. A typical source of events is the aggregates. When something happens within the aggregate, it will raise an event. In the Axon f/w, events can be any object. it’s highly encouraged to make sure all events are serializable. Event Sourcing Handlers combined will form the Aggregate, this is where all the state changes happen.
- Event Dispatchers
- Event Handler
- Event Processors
- Event Bus
- Event Store
- Event Versioning
Axon Server
Now that we have the Axon Server side of things, we expect things here concerning both message handling and event storage. Axon Server comes with a zero-configuration message router and event store that are combined gracefully with Axon to provide a solution to both storing events and delivering messages between components.
Needless to say, it ticks all these boxes. An axon server is built from scratch in Java to specifically meet all of these requirements. It manages files directly and does not depend on an underlying database system to store events.
Event Sourcing
Event Sourcing is an Architectural pattern in which Events are considered the “source of truth”, based on which components are build their internal state.
EventStore
The database “EventStore” (written with quotes to emphasize it is the name of the database) is a built-for-purpose solution and therefore, it meets all the requirements in our list. “EventStore” is a popular option that is written in .NET (with Java clients written using Akka). Axon Framework gives a huge selection of options for where to store your events in traditional RDBMS options like PostgreSQL or MySQL to NoSQL databases such as MongoDB.
Summary
In this blog, we’ve summarized the requirements a query, command, message, and Event Store database needs and looked at the various options available together. Axon’s set of features and performance of your Event Sourcing system, we recommend specialized storage and, particularly if you are already leveraging Axon Framework, choosing Axon Server is a logical choice to make.
