Axon Trader Reference Documentation
Welcome to the reference documentation to help you understand the ins and outs of the Axon Trader example application. Here you will find an ever expanding knowledge base of information to help you get the most out of the reference example’s end-to-end source code—from build to deployment.
The Axon Trader reference application is a comprehensive event-driven architecture. The architecture has the following unique characteristics.
-
Cloud-native application
-
Step-by-step deployment scripts
-
Concourse pipeline for CI/CD
-
Spring Boot
-
Spring Cloud
-
CQRS+ES with Axon Framework
-
Easy deployment to Pivotal Web Services (Cloud Foundry)
To get started, follow the step-by-step guide included in the README on the GitHub landing page of this project.
The Axon Trader application has its roots going back to 2012, when Allard Buijze and fellow committers created the original Axon Trader example application. You can get more information about the general architecture and ideas behind the domain at the wiki page referenced in the original application.
The main goals of this new wiki page is to extend on the ideas presented in the original Axon Trader application, but with a focus on the cloud-native integrations with Spring and Pivotal Cloud Foundry.
The Axon Trader application is realistically complex, modeled after a high-velocity event-driven stock trading application. Due to the complexity in the domain, it may be difficult at first to grasp some of the concepts—should you be unfamiliar with the subject matter. I’ve constructed a domain graph that should somewhat help clarify the interactions between different domain objects, which you will encounter as aggregates and value objects inside of the reference application’s source code.
A cloud-native event-driven architecture is not easily defined outside the boundaries of a closed-source implementation inside the boundaries of an innovative company. If you’ve used Axon in the past, it’s important to understand that this reference application is the only existing end-to-end example of a cloud-native EDA (event-driven architecture) that utilizes the most modern components of the Spring ecosystem.
The term Event Sourcing is relatively new to the history of the world. The earliest reference that I could find about Event Sourcing is in a blog post first published by Martin Fowler in 2005.
Event Sourcing ensures that all changes to application state are stored as a sequence of events. Not [only] can we query these events, we can also use the event log to reconstruct past states…
http://www.martinfowler.com
The idea that a log of events can be used to reconstruct past states is not at all new. Long before Fowler first wrote about Event Sourcing, Sailors in the 15th and 16th century used the word log to describe a system that measured the speed of nautical vessels. As a part of this system, Sailors employed a mechanical device named a chip log, which is similar to the spool of a fishing rod. The spool of the chip log was wound with a thin rope, dubbed a "log-line", and was knotted at equally spaced intervals.
Instead of a fishing hook, a wooden plank was attached to the log-line and would be dragged behind the boat like an underwater parachute. Sailors would then let the log-line unwind itself—with the drag of the ocean pulling the knotted rope away from the ship for a fixed interval of time. The faster a boat was traveling, the faster the log-line would be unwound. At the end of the fixed interval, the log-line would be rewound on the spool while counting the number of knots that passed through a sailor’s hand. A ship’s speed was calculated by counting the total number of knots unspooled during the fixed time interval. By rewinding the rope, the sailors would actively follow their observations back to the source. Today, we do as the sailors do, but instead of knots on a rope, we use events stored on a computer. We call this activity Event Sourcing.
