This project has some sample code for my personal learning purpose. Things which I've learnead are collected as issues here: https://github.com/nowakprojects/SelfImprovement/issues
107
stars
17
forks
source link
AxonIQ | How I accidentally built a framework, and now own a business supporting it #5780
One of the most common questions I get is: “How did you decide to build the Axon Framework?” The answer may be a bit surprising: I never did. It was not meant as a framework.
It was 2008, I was fed up with yet another project exploding in complexity. No matter how I decided to “do it right this time”, each time the solution felt more complex than the problem it solved.
I had applied Domain Driven Design (DDD) and it certainly helped tackle some of the complexity. Yet, there is always a point where things go awry. It usually starts with the customer or project owner walking in saying “oh, one more thing”. The software was flexible, could deal with change, but just not that one. There had to be another way…
Greg Young had done a talk about Command-Query Responsibility Segregation (CQRS) and Event Sourcing. His advice: it’s not one model, but several. Split the reads from the writes. I wanted to see if these concepts could help with my problem.
I worked for a very innovative and open-source-minded company at that time. They were at the cradle of Spring as well as Elastic. My boss allowed me to do an experiment, one day per week, as long as the code was open source, wrote a blog about it, and presented my findings in our monthly meetup. Deal!
Day 1. Problem. When creating a repository to publish code, it needs a name. I was just trying to figure out how CQRS would work in Java. Having a chronic lack of inspiration, I called it cqrs4j. I also thought of a small use case that I wanted to implement: a simplified version of an actual project I was working on in the online retail domain. How hard could it be?
Several days in, I found out that to make things work, I needed to write quite a bit of plumbing. Code that had absolutely nothing to do with the functionality. I thought: if it has nothing to do with the domain, everyone will need to do this. Let’s put it in a separate module.
Fast forward a few weeks. The generic module was teeming with code. The functional module didn’t contain that much code. And that was a good thing. A lot of the technical concerns were separated from the functional ones, and the functional code was clean and easy to understand.
I wrote my blog and spoke at the meetup. Then I shared my findings at a conference. And another. I received an email from a French company: “We’re using your framework and are about to go into production with it”. 😱 Because not every project is as mission-critical as another, I asked: “You know it’s not production-ready at all, right? What are you using it for?”. They responded: ”We tested it thoroughly and it works as expected. It is an application used by surgeons to track the tools they use during surgery.” What?!
I continued working on the project to evolve it into something usable. My colleagues also helped find a better name for the project: Axon Framework. By 2015, it had been used to successfully deliver a medical case management tool, a gaming platform that allowed its users to play Bridge tournaments online, and an assessment platform for computer-based tests for driver's licenses.
The platform has evolved a lot since then, but our mission is still the same: allow the software we build to efficiently deal with the complexity of our domain. Check our website to see how we do it: www.axoniq.io.
One of the most common questions I get is: “How did you decide to build the Axon Framework?” The answer may be a bit surprising: I never did. It was not meant as a framework.
It was 2008, I was fed up with yet another project exploding in complexity. No matter how I decided to “do it right this time”, each time the solution felt more complex than the problem it solved.
I had applied Domain Driven Design (DDD) and it certainly helped tackle some of the complexity. Yet, there is always a point where things go awry. It usually starts with the customer or project owner walking in saying “oh, one more thing”. The software was flexible, could deal with change, but just not that one. There had to be another way…
Greg Young had done a talk about Command-Query Responsibility Segregation (CQRS) and Event Sourcing. His advice: it’s not one model, but several. Split the reads from the writes. I wanted to see if these concepts could help with my problem.
I worked for a very innovative and open-source-minded company at that time. They were at the cradle of Spring as well as Elastic. My boss allowed me to do an experiment, one day per week, as long as the code was open source, wrote a blog about it, and presented my findings in our monthly meetup. Deal!
Day 1. Problem. When creating a repository to publish code, it needs a name. I was just trying to figure out how CQRS would work in Java. Having a chronic lack of inspiration, I called it cqrs4j. I also thought of a small use case that I wanted to implement: a simplified version of an actual project I was working on in the online retail domain. How hard could it be?
Several days in, I found out that to make things work, I needed to write quite a bit of plumbing. Code that had absolutely nothing to do with the functionality. I thought: if it has nothing to do with the domain, everyone will need to do this. Let’s put it in a separate module.
Fast forward a few weeks. The generic module was teeming with code. The functional module didn’t contain that much code. And that was a good thing. A lot of the technical concerns were separated from the functional ones, and the functional code was clean and easy to understand.
I wrote my blog and spoke at the meetup. Then I shared my findings at a conference. And another. I received an email from a French company: “We’re using your framework and are about to go into production with it”. 😱 Because not every project is as mission-critical as another, I asked: “You know it’s not production-ready at all, right? What are you using it for?”. They responded: ”We tested it thoroughly and it works as expected. It is an application used by surgeons to track the tools they use during surgery.” What?!
I continued working on the project to evolve it into something usable. My colleagues also helped find a better name for the project: Axon Framework. By 2015, it had been used to successfully deliver a medical case management tool, a gaming platform that allowed its users to play Bridge tournaments online, and an assessment platform for computer-based tests for driver's licenses.
The platform has evolved a lot since then, but our mission is still the same: allow the software we build to efficiently deal with the complexity of our domain. Check our website to see how we do it: www.axoniq.io.