Why use “Clean Architecture” in our projects?

This article’s objective is to explain the reasons that led me to propose “Clean Architecture” as an architecture to develop projects in our company. After learning about it, the Codegenio projects are developed following this architecture and we solve the problems of coupling, maintenance and productivity in general. Before being able to answer why are we using this architecture, I present some basic concepts for greater understanding.

What is Software Architecture?

It consists of a set of coherent patterns and abstractions that provide a clear and defined framework to interact with the software source code, allowing programmers, analysts and the entire set of software developers to share the same line of work and cover all objectives and application restrictions. It is considered the highest level in the design of the architecture of a system since they establish the structure, operation and interaction between the parts of the software.

What is Clean Architecture?

Clean Architecture is a compendium of development principles and patterns that aim to facilitate the software construction process, as well as its maintenance. It refers to organizing the project making it easy to understand and change as the project grows or one of the technologies used needs to be replaced, either because it has become obsolete or for any other strategic reason.

Similarities between architectures

Applying Clean Architecture was not so difficult to assimilate by the team. Domain-oriented architectures such as the Layered Architecture proposed by Eric Evans, Uncle Bob’s Clean Architecture, Jeffrey Palermo’s Onion Architecture have features in common with it.

Each of these architectures produces systems that have the following characteristics:

• Independent of frameworks. The architecture does not depend on the existence of some library of feature-laden software. This allows you to use such frameworks as tools, rather than forcing you to cram your system into their limited constraints.
• Testable. The business rules can be tested without the UI, database, web server, or any other external element.
• Independent of the UI. The UI can change easily, without changing the rest of the system. A web UI could be replaced with a console UI, for example, without changing the business rules.
• Independent of the database. You can swap out Oracle or SQL Server for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.
• Independent of any external agency. In fact, your business rules don’t know anything at all about the interfaces to the outside world.

The following diagram is an attempt at integrating all these architectures into a single actionable idea.

Benefits

• Creating decoupled applications that are easier to test.
• Greater flexibility to add or remove software features.
• Component-based design with well-defined responsibilities.
• Postponement of critical decisions until the last required moment.

Main Uses

• Business applications projected that are in operation indefinitely.
• Distributed systems that benefit from an uncoupled design (e.g. using microservices).
• Heterogeneous infrastructures at the level of databases, web services, etc.
• Applications designed to be extended by third parties through plugins.

Conclusion

Conforming to these simple rules is not difficult, and it will save you a lot of headaches going forward. By separating the software into layers and conforming to the Dependency Rule, you will create a system that is intrinsically testable, with all the benefits that it implies. When any of the external parts of the system become obsolete, such as the database, or the web framework, you can replace those obsolete elements with a minimum of fuss.

These advantages are not obtained by chance, intentional planning is needed, because of them, our company uses Clean Architecture.

This article was originally posted by Marcos Gonzalez at Codegenio’s blog.