As software development continues to evolves, new architectural patterns appear and get popularized. Recently, the Software Craftsmanship trend is pushing a lot of buzz about Onion architecture, Hexagonal architecture and Clean architecture. What do these architectures have in common ? Can we extract some common-sense principles and get them checked with static code analysis tools ?
A quick introduction to the Clean architecture
The clean architecture principle has been described by Robert C. Martin (Uncle Bob) in 2012 on its blog ( link ).
Though these architectures all vary somewhat in their details, they are very similar. They all have the same objective, which is the separation of concerns. They all achieve this separation by dividing the software into layers. Each has at least one layer for business rules, and another for interfaces.
No matter the number of layers, we find the following architecture principles:
Abstraction: Frameworks, external agents; databases are accessed through facades and API. These facades are for the database an ORM, for a rest client, a plain interface or an Adapter design pattern. Package and class dependencies should be checked also to avoid circles and spaghetti code.
Isolation: For each module; we should be able to write them separately, check their behavior and connect them with the rest of the system. A way to implement such modular architecture is to rely on the use of Value objects or DTO and clean API.
Testability: a clean architecture should be flexible and use-cases oriented. The usage of TDD and a testing framework are recommended to organize your code and make it easy to use.
Clean architecture potential flaws
Like all software modeling; Clean architecture comes with its own flaws.
DRY violation: the isolation between the layers and the modules may create a ton of unnecessary code aka DTO and Value objects. When a data cross the boundaries; it must not contain any technological signature from the other module. Therefore it creates redundancy to achieve this result.
Anemic domain model: when everything is abstracted, the big question is where will you store the business code? DDD and Clean architecture tends to have domain models without any code but plain getter/setters.
Surely there are others, but there are the two most annoying flaws IMHO.
Static code analysis tools to produce a clean architecture ?
For the sake of brevity, I retained three tools.
ArchUnit and its Maven plugin SonarQube, the well-known but aging code quality platform Embold.io, a new static code analysis tools Saas platform that promises an updated static analysis engine that fits our modern needs ArchUnit : unit test your architecture
This Java framework allows you to write architectural rules and ensures they are applied on your application. The maven plugin associated with allows you to run and produce a report in your CI/CD environment.
Traditionally I will use this plugin to assess if the layers and the boundaries are respected. You may have a look to their example here to get an idea.
SonarQube: Code Quality and Security
I have been an intensive user of SonarQube since the early versions and their current pivot towards Code reviewing is somewhat disputed among the community of tech-leaders and software craftmanshippers. Certainly to have a tool easier to use is great but important features have been deleted like Software architectureContinue reading