No Framework

Axon Framework is an open-source framework frequently used for building event-driven microservices on the JVM. Its architectural concepts are CQRS (Command Query Responsibility Separation), DDD (domain-driven design), event sourcing, and location transparency.

The choice of using a framework for application development is somewhat controversial. You might have a look at this blog by Peter Kummins, which argues against the use of frameworks in general. More specific to the field in which Axon operates, father-of-CQRS Greg Young is known for advising “don’t write a CQRS framework,” and DDD authority Mathias Verraes recommended not to use a framework for applications that have to last multiple years on Twitter. This blog by Tomas Petricek makes some other interesting points, clearing distinguishing between libraries and frameworks, and advocating the use of libraries over frameworks.

As you might imagine, at AxonIQ, being the company behind Axon Framework, we strongly believe in the value of using a framework for business applications. Given the controversy, we thought it might be useful to explain the reasoning behind this. We’ll start by looking at frameworks in general, and then zoom in to the reasons for using a framework like Axon in particular.

Frameworks in general

What is a framework?

Fundamentally, a framework is a special kind of library. A library is a body of code (classes, functions) that is used by a given business application, without being part of that business application. Projects typically import libraries through tools such as Maven, npm, or NuGet. For the developer of the business application, using a library has the benefit of reducing work and bug potential: the library has already been written and tested.

For regular, non-framework libraries, the application developer will simply interact with the library by doing function and method invocations to code in the library. The interaction with a framework is different. When using a framework, developers write code “following the framework.” Practically, that means that the application code implements certain framework interfaces, or uses annotations defined by the framework. During program execution, the framework invokes the application code and not the other way around.

Now that we defined the framework concept let’s have a look at some reasons to use one.

You’re using a framework anyway

The idea of writing a business application without using a framework is somewhat of a mirage. You might start such a project by using the Java platform, and start your code in public static void main(String[] args). But does that mean you’re not using a framework? No, it doesn’t. The Java platform is providing a huge layer of abstraction over the operating system and machine you’re working on, and this platform is the thing that is invoking the business application code. So, the Java platform is a framework. You may choose to use something even more primitive, but there is no real escape – it is frameworks all the way down.

In reality, most developers don’t start by implementing a standard program entry point like this. Most business applications implement some web-based interface and rely on some abstraction layer to create entry points to the application other than the main method. For instance, this could be a Java EE HttpServlet, a JAX-WS @WebService, or a Spring Web @RestController. This relieves the application developer of the burden of thinking about HTTP protocol implementation and connection management - the framework takes care of this.

The point is this: there is no choice between using a framework and not using a framework. There will be frameworks. The real architectural choice is: what kind of framework do I use? There’s a real choice between frameworks at different abstraction levels.

Certain types of re-usability require a framework

The core motivation behind libraries in general (including regular libraries and frameworks), is to reuse code. Some types of code easily fit in the regular library model. For instance, we might have a set of functions to do matrix algebra. These could be put in a regular library and reused by any application that needs matrix functionality.

Other types of reusable code don’t fit into this model. A key example of this is the functionality of implementing the HTTP protocol and executing certain business logic depending on the details of the request. The HTTP implementation is generic functionality that should not be in the business logic. But it is also very clear that when a call comes in from a user, it will first end up at the HTTP implementation, which would then invoke the business logic and not the other way around. The only natural way to make a reusable implementation of HTTP is by using the framework pattern, which again shows that frameworks are unavoidable.

Axon Framework

What kind of framework is Axon?

Axon is a framework that implements reusable code in the area of CQRS, DDD, and event sourcing. It implements the notions of command, event, and query messages, with the associated buses and handler methods. This leads to location transparency: the buses can have local or distributed implementations without changing the business logic code. For DDD, it implements core notions such as Aggregate and Repository. To enable event sourcing, it implements the notion of applying an event to an aggregate, the event store, and an event-sourced repository.

Comparing it to a web framework, Axon operates at a higher level of abstraction. The core notion is the exchange of messages (independent of transport mechanism). Axon will invoke the appropriate business code given a message. By definition, this can only be done by a framework, not by a regular library.

For this discussion, we start with the assumption that we want to use DDD, CQRS, and/or event sourcing principles in a business application. (If not, using Axon doesn’t make any sense.) Given this assumption, what are the reasons for choosing Axon Framework?

Focus on the business

By using Axon Framework, developers can use its architectural concepts without having to implement any generic code first. They can exclusively focus on the code that is specific to the business domain. That sounds simple, but it’s a huge benefit. It means less development cost, shorter time to market, more predictable development, less risk. In and by itself, this is an excellent reason to use Axon Framework.

This benefit is further enhanced by Axon’s implementation of location transparency. Messages can be handled locally (in a monolith) or in a distributed fashion (a microservices system), transparent to the business logic and without necessitating writing REST endpoints and clients. This saves a lot of code and again allows a strong focus on business functionality.

Avoid the DIY framework

In reality, the alternative to using a framework is not so much not using a framework. It is using a home-grown/do-it-yourself (DIY) framework. It happens almost automatically. Any capable developer tries to implement separation of concerns, and implementing DDD, CQRS, and event sourcing concepts, is a different concern from using these building blocks in business logic. So you put these generic implementations in a “common” module, subproject, or similar. That’s the seed of the DIY framework.

That’s a bad thing for several reasons. First of all, time spent on the DIY framework is time not spent on the business logic. But it gets worse. Most likely, the DIY framework will be still somewhat specific to the needs of one application. Most likely, the flexibility and documentation of the DIY framework will not be on par with a true open source framework like Axon. As a result, the DIY framework code will probably not be reused across the business’ application portfolio, leading to additional costs.

Another pitfall with the DIY framework is that it appears to be simple… in the beginning. Writing some initial code that implements Axon’s core principles from scratch would probably just take a couple of days. We know from experience that implementing all kinds of highly desirable features beyond that, takes years. Starting with the DIY framework is not a small investment into the application upfront. It will continue to be a concern and cost factor as the application evolves.

Finally, as a skill set, writing framework code is different from writing business application code that uses a framework. By using an external framework rather than the DIY approach, teams can consist of developers that naturally focus on the business application part.  

A good framework doesn’t significantly limit flexibility

One of the arguments brought forward for libraries over framework is that libraries offer more flexibility, for instance when combined with other libraries. In reality, this highly depends on the framework. If a framework is closed for extension (or maybe even closed source) and just invokes the business application code, that’s probably true. If most core concepts in a framework are defined in open interfaces, and the framework itself is open source, it’s not.

Axon belongs in that latter category. Developers combine it with Spring, with Java EE, with vanilla Java. They combine it with all kinds of infrastructure - RDBMS, Mongo, Kafka, Axon Server, RabbitMQ, Eureka. The open interfaces enable this.

Conclusion

This debate is about picking the right tool for the job. If the job at hand is to implement a microservices system using DDD, CQRS and event sourcing principles, it makes a lot of sense to pick a tool that does just that. Axon is such a tool.

You can download open source Axon here.