Axon Framework Documentation

Axon Framework provides performance guidance across several key areas to optimize application throughput and latency. Tuning focuses on:

• Command Processing: Managing command sequencing and avoiding optimistic locking conflicts for the same entity.
• Event Processing: Tuning pooled streaming event processors for throughput, claim management, and batching.
• Relational Database Tuning: Adjusting schema and database settings specifically for the JPA-backed event store.
• Snapshotting: Reducing entity rebuild time by creating snapshots at strategic intervals (available in advanced framework configurations).
• Caching: Reducing event store traffic by caching data close to the application (available in advanced framework configurations).

Axon Framework provides metrics for message-centric systems (counts, capacity, and latency) through two extension modules:

1. axon-metrics-dropwizard: Uses Dropwizard Metrics and registers measurements against a Dropwizard MetricRegistry.
2. axon-metrics-micrometer: Uses Micrometer for dimensional-first metrics collection, registering against a Micrometer MeterRegistry.

These modules allow you to monitor components like CommandBus, EventBus, QueryBus, and EventProcessors using various MessageMonitor implementations.

A StreamingEventProcessor (or Streaming Processor) handles events by receiving them from a StreamableEventSource (such as an EventStore).

Key characteristics include:

• Decoupling & Parallelization: Uses separate threads to process events, decoupling event handling from command handling or event publication.
• Resiliency: Uses TrackingTokens to maintain progress, allowing the processor to resume from where it left off after shutdowns.
• Replay-ability: Allows replaying events by adjusting the position of the tracking tokens.

Default Behavior:

• If an EventStore is present, the Pooled Streaming Event Processor (PSEP) is the default.
• If only an EventBus is configured (no StreamableEventSource), the framework falls back to a Subscribing Event Processor.

Axon Framework is a framework designed for building evolutionary, event-driven microservice systems. It is based on the principles of Domain-Driven Design (DDD), Command-Query Responsibility Separation (CQRS), and Event Sourcing.

Key building blocks provided by the framework include:

• Aggregate design handles and repositories
• Command buses
• Saga design handles
• Event stores
• Query buses

The framework uses messaging for commands, events, and queries to provide location transparency, which enables an evolutionary approach to microservices. For distributed implementations (scalable command, event, and query buses, and an efficient event store), Axon recommends using Axon Server.

Axon Framework provides several built-in mechanisms for observing application behavior:

• Tracing: Distributed tracing support to track message flow.
• Metrics: Configuration and usage of metrics provided by the framework.
• Health Indicators: Spring Boot actuator health indicators for monitoring application status.
• Event Processor Monitoring: Tracking the specific status of your event processors.
• Message Tracking: Tracking the origin and flow of messages throughout the application.

Axon Framework decouples message identity from Java class representation using a MessageType. A MessageType consists of a QualifiedName (comprising a namespace and a name) and a version.

• Namespace: Defaults to the package name of the message class.
• Name: Defaults to the simple class name.
• Version: Specified via annotations.

This allows the same message (e.g., com.example.events.UserRegistered version 1) to be represented by different Java classes in different services, as long as the MessageType matches.

Axon Framework uses message metadata to track relationships between messages in a workflow. This allows you to trace a business transaction from its root cause through all subsequent commands and events.

• Correlation ID: The identifier of the original message that started the entire business transaction or workflow (the root cause).
• Causation ID: The identifier of the immediate parent message that directly caused the current message to be created.

In a chain of messages, all messages share the same correlationId to allow full workflow tracing, while each message's causationId points to its immediate parent to reconstruct the specific message chain.

To support versioning, non-JVM systems, and schema evolution, Axon Framework 5 decouples message identity from Java types.

• QualifiedName: Represents the business identity of a message, independent of the Java class name.
• MessageType: Used to define the identity and version of a message.

This allows version negotiation to happen at the message level rather than the serializer level.

Axon Framework uses message objects for all component communication, providing location transparency for scaling and distribution. All messages implement the Message interface and consist of four core components:

• Message Type (MessageType): Describes the meaning of the message (e.g., OrderPlaced), decoupled from the underlying Java class.
• Payload: The actual data/information related to the message.
• Metadata: Contextual information (e.g., tracing, auditing, security context). Note: Do not base business decisions on metadata; use it for reporting and tracing.
• Identifier: A unique ID for the specific message instance.

Crucial Property: Immutability All messages are immutable. To add data to a message, you must create a new message based on the previous one. This ensures safety in multi-threaded and distributed environments.

Axon Framework is a messaging-centric framework designed for building applications using CQRS (Command Query Responsibility Segregation) and Event Sourcing patterns. It revolves around three primary message types:

• Commands: Messages expressing an intent to change the system state.
• Events: Messages representing facts about what has already happened in the system.
• Queries: Messages requesting information from the system.

Additionally, the framework supports Domain-Driven Design (DDD) practices by providing tools for building entities and managing domain logic.

Axon Framework provides two primary interfaces for dispatching queries:

1. QueryBus: A low-level infrastructure component used to dispatch queries to handlers via a registered query name. It does not support scatter-gather queries (where multiple handlers respond to one query).
2. QueryGateway: A high-level, convenient API recommended for typical application code. It abstracts message creation and wraps query payloads into Query Messages automatically.

Axon supports three query types:

• Point-to-point: Request to a single handler.
• Subscription: Initial state plus subsequent updates.
• Streaming: Large result sets delivered via reactive streams.

Workaround for Scatter-Gather: If you need to collect data from multiple sources, use multiple separate queries or implement an aggregating query handler that coordinates data collection internally.