Preferring frameworks or libraries is somewhat controversial, Frans van Buul, commercial director and evangelist at AxonIQ, the company behind Axon Framework, writes in a recent blog post. Many argue in the favour of libraries but Van Buul thinks that a framework can be very valuable when building business applications. He believes this to be especially true for applications using the architectural concepts found in Axon — CQRS, DDD and event sourcing.
A library is defined by Van Buul as a body of code, consisting of classes and functions, which is used by an application, but without being part of that application. An application interacts with the library by doing function or method calls into the library. He defines a framework as a special kind of library where interaction is the other way around, an application now implements interfaces in the framework, or use annotations from it. During execution the framework invokes application code; using a library it’s the other way around.
Creating an application without using a framework is for Van Buul somewhat of a mirage, claiming that even if you just use the Java platform, you are also using a framework. He points out that the Java platform is an abstraction over the operating system and the machine and that the platform is invoking the application code. He also notes that most business applications have a web-based interface and use an abstraction layer to create entry points into the application — meaning a framework is used.
Reasoning about the advantages of using a framework, Van Buul assumes that CQRS, DDD and event sourcing are requirements. His first argument is that it allows developers to focus on the business domain instead of on infrastructure. He believes that in practice the alternative is not to use a library, but to build your own framework. This can in the end be a very complex task and force developers to spend a lot of time creating the framework. He claims that this will both increase the risk and the cost and strongly advices against doing this. He refers to Greg Young, who coined the term CQRS, and his presentation at DDD Europe 2016 where he advised:
Don't write a cqrs framework
Peter Kummins sees frameworks as one of the largest anti-patterns in system development, arguing that they are hard to learn and increase a project’s complexity and dependencies. He claims that software should be developed using the least amount of complexity, using fundamental tools that have been and will be around for the next 20 years, and prefers using core language solutions and small abstractions or helper libraries before general libraries and frameworks.
Kummins’ main reasons for not using frameworks include that they:
- are hard to learn, and this knowledge is generally useless
- limit your scope of creativity
- increase a project’s complexity
- go out of business
Mathias Verraes agrees with the definition of a framework and refers to the mnemonic:
A library is something your code calls, a framework calls your code
He argues against frameworks, claiming that the cost of a boilerplate in a system that is 10 years old is negligible, compared to the cost of badly understood, obsolete or plain wrong abstractions. His recommendation is therefore to use frameworks only for applications with a short development lifespan, and to avoid frameworks for systems you intend to keep for multiple years.
Tomas Petricek uses the same framework definition and argues that the biggest and most obvious problem with frameworks is that they cannot be composed. When using two frameworks there is commonly no way to fit one of them into the other; when using two libraries this is easily done. He also notes that frameworks are hard to explore and affect the way you code.
Petricek refers to functional library design principles and points out that one way of getting away from frameworks and callbacks is to use asynchronous workflows and an event-based programming model. Instead of writing abstract or virtual methods that need to be implemented, events are exposed and triggered when an operation needs to be done. He notes that with this model, although we are not in full control since we don’t know when an event is triggered, we are in control after that. Reversing the control this way makes it possible to use composable libraries instead of frameworks and to choose which library to use for a specific part of a problem.
In conclusion, Van Buul notes that one argument for favouring libraries is that they are more flexible, but claims that this depends on the framework. For a framework closed for extension it’s probably true, but for an open source framework with core concepts defined as open interfaces, he believes it can be as flexible as a library.
