DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Related

  • DevOps Fast Forward with Go
  • 11 Observability Tools You Should Know
  • Monolithic First
  • Keep Your Application Secrets Secret

Trending

  • Memory Leak Due to Time-Taking finalize() Method
  • Integrating Model Context Protocol (MCP) With Microsoft Copilot Studio AI Agents
  • The Full-Stack Developer's Blind Spot: Why Data Cleansing Shouldn't Be an Afterthought
  • Metrics at a Glance for Production Clusters
  1. DZone
  2. Data Engineering
  3. Data
  4. No Framework for Your Microservices?

No Framework for Your Microservices?

We explore the reasoning behind using frameworks in microservices development before looking at how the OS framework, Axon, works.

By 
Frans van Buul user avatar
Frans van Buul
·
Feb. 11, 19 · Analysis
Likes (10)
Comment
Save
Tweet
Share
12.2K Views

Join the DZone community and get the full member experience.

Join For Free

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 Segregation), 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 my organization, Axon operates, father-of-CQRS Greg Young is known for advising “don’t write a CQRS framework,” and DDD authority Mathias Verraes recommended on Twitter not to use a framework for applications that have to last multiple years. This article by Tomas Petricek makes some other interesting points, clearly distinguishing between libraries and frameworks, and advocating for the use of libraries over frameworks.

As you might imagine, at AxonIQ, being the company behind the 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 into 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.

Image title

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 a 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 Reusability 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 Aggregateand 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.

Image title

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 the Axon framework?

Focus on the Business

By using the , 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.

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 business logic. But it gets worse. Most likely, the DIY framework will be still somewhat specific to the needs of one application. Most likely, 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 frameworks is that libraries offer more flexibility, for instance when combining 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 infrastructures — 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.

If you want to check out Axon yourself, you can download the quick start package here.

Framework application Library microservice Business logic Open source dev Event operating system

Published at DZone with permission of Frans van Buul. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • DevOps Fast Forward with Go
  • 11 Observability Tools You Should Know
  • Monolithic First
  • Keep Your Application Secrets Secret

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!