As software development continues to evolve, new architectural patterns appear and become 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 how can we improve them with static code analysis tools?
A Quick Introduction To 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 otherwise quiet 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 and databases are accessed through facades and APIs. 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. One 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-case oriented. The usage of TDD and a testing framework are recommended to organize your code and make it easy to use.
Potential Pitfalls In A Clean Architecture
Like all software modeling, clean architecture comes with its own set of pitfalls:
- DRY violation: the isolation between the layers and modules may create a ton of unnecessary code aka DTO and Value objects. When data crosses 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 these are the two most annoying flaws in our opinion.
Static Code Analysis Tools To Produce A Clean Architecture?
For the sake of brevity, we compared Embold and ArchUnit for you.
- ArchUnit and its Maven plugin
- Embold.io, a new static code analysis tool that promises an updated static analysis engine to fit more complex design 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 it allows you to run and produce a report in your CI/CD environment.
Traditionally, one can use this plugin to assess if the layers and the boundaries are respected. You can take a look to their example here to get an idea.
Embold: The Quality Of Predecessors And A Little Extra
Embold is a rather innovative solution for testing architecture due its in-depth recognition of design patterns and issues. Here’s some advantages:
I have been using it recently on my new projects. It provides me something different from the previous two tools.
- Architectural and application design code smells: Embold is great at sniffing out architecture flaws like higher abstraction code smells
2. Duplication code analysis: the duplication analysis is as good as CPD/ SonarQube.
3. Heatmap: The heatmap is really useful to check your Software quality at a glance.
4. Testability and test priority: in each of your software assessments, Embold gives you a priority list for the classes you need to test. This helps you address issues quickly and safely. Unlike any other static analysis tool on the market, with Embold, you have the list ready-made—no need to build an Excel with extracted metrics like in SonarQube.
Conclusion
It is no surprise that there is no tool to fit all usage. However, using static analysis tools, you can easily instrument your projects with minimal effort. They allow you to detect, and thereby fix, most of the flaws needed to achieve a cleaner architecture.
Comments are closed.