Software code consists of multiple layers that are sometimes too closely intertwined, limiting developers’ freedom. The “clean architecture” approach ensures that you can program from scratch.

What do software code and lasagna have in common? This is not the start of a silly puzzle, but a question that has been bothering developers for a long time. Just like lasagna, code is made up of multiple layers that come together to form a whole. The interaction of these different layers determines the success or failure of your recipe.

In a perfect lasagna, the different layers fuse together, but for code this is not the ideal preparation method, we learn from Maarten Vandeperre. He’s not a professional chef, but… Specialized solutions architect at Red Hat. Clean architecture moves away from the idea that software layers are intertwined and strives for a stricter separation between the layers. This way, a developer does not have to worry that changes in one layer will affect the entire architecture.

Onion structure

The founder of the clean architecture approach is Robert C. Martin. He wrote the book in 2008 The Clean Coder: A book that was an important source of inspiration for Vandeperre. Martin divides software code into four levels according to the principle of an onion structure.

Vandeperre takes us through a visual representation of clear architecture. “In the outer layer is the runtime configuration, which is the glue that shapes the underlying layers or a subset of them into an executable program. The second outer layer of the onion contains the infrastructure layer, which includes databases, networking and web frameworks. This layer does not contain much code, but it contains necessary references to details in the code.”

“If we peel away this layer, we get to the ‘adapter layer,’” Vandenperre continues. “This layer forms the buffer between the ‘inside’ and the ‘outside’ of your code. The gateways and controllers that regulate data traffic between the different levels are defined here.”

Layer by layer we get to the core of your code. In the third layer, application-specific business rules are defined for specific use cases of an application. Finally, the innermost layer is the domain layer. This is where company-wide data structures and functions are set in stone.

Keep your options open

A clear architecture creates a clear hierarchy between these levels. Vandeperre explains: “Be strict about where dependencies are allowed in your code structure. These must only face inwards, meaning outer layers can depend on inner layers, but not the other way around, to reduce the risk of regression. With a clean architecture, there can still be duplicate pieces of code, but they are much more isolated from each other. The inner layer should be as independent as possible. This is really crucial for clean architecture to work.”

“This way you keep all options open: you don’t have to marry technology,” Vandeperre continues. “If you depend too much on a particular software, database or library, problems can arise. For example, I often see developers giving Quarkus access to the core of their code. The only allowed dependency here is the programming language itself, but that doesn’t mean that everything that comes with a particular programming language has to be in your core.”

This way of working offers many advantages when testing your code. “Testing runs much more smoothly because the core is not affected,” Vandeperre continues. “You can set up separate testing processes at each level to determine where errors occur. The cost of throwing away things that don’t work is reduced because adjustments you make to the infrastructure don’t impact the core. That gives you more freedom to try new things.”

If you depend too much on a particular software, problems can arise. Give yourself the freedom to try new things.

Maarten Vandeperre, Specialist Solutions Architect Red Hat

From the inside to the outside

In addition to testing, a clean architecture should also promote code execution and maintenance. “The order of development is actually reversed: you no longer work from the outside in, but from the inside out.” You can first develop the business logic and the data model. Only when you know that the core is there can you continue building the additional layers. This is exactly why it is so important that your core is independent: once an addiction creeps in, it is very difficult to eliminate it,” says Vandeperre.

From his own experience, Vandeperre offers one final golden tip for getting started with clean architecture: “Think beyond the principles of the code itself and don’t forget the infrastructure layer.” This may be outside of your code, but it is the layer that ultimately matters makes everything coherent. The infrastructure should therefore not be viewed as one layer, but as a combination of several sub-levels, such as interfaces, network, databases, etc. I come from the software world and have had to experience this to my own shame.”