Nowadays, in the world of software, so-called Clean Architectures are widely used. They are known as such because they are all based on the same software design principle: separation of responsibilities. One of the best known is the hexagonal architecture, but there are many others. On this occasion, we tell you what you need to know to understand when and why to use a Clean Architecture.
Parts or levels of a Clean Architecture
– Infrastructure: these are the external elements with which the application communicates, both input and output:
- Entry points: an API with REST or GraphQL, messaging with RabbitMQ or via the command line, etc.
- Exit points: a relational database with PostgreSQL, non-relational with MongoDB, or also sending messages with RabbitMQ, etc.
– Application/Use Cases: it deals with the evaluation of business rules and decision making. They contain the rules that give meaning to the application. Use cases direct the flow to the entities and orchestrate them to accomplish the business.
– Domain: it responds to the application data model, domain services, interfaces, etc. Entities are the defined models that interact in the system; they must be abstract enough to be used by multiple applications in the business.
Principles of Clean Architecture
1. Independent of any framework
The clean architecture must be able to be applied to any system, regardless of the programming language or libraries it uses. The layers must be so well separated that they can survive individually, without the need for externals.
2.Testable
The purer a function, class or module is (that is, without side effects), the easier it is to predict the result that will be obtained. Each module, both UI, database, API Rest connection, etc., must be able to be tested individually.
3. Independent user interface (UI)
One of the components that undergoes constant changes is the user interface. The UI must be able to change without disrupting the entire system. If we go further, this layer should live so independently as to be disassembled and replaced by another. For example, being able to change a Mobile UI for one in console mode.
4. Database independent
As in the previous item, this layer must be so modular as to add multiple data sources and even multiple sources of the same type of data. For example, handling various databases like MySQL, PostgreSQL, Redis, etc.
5. Independent of any external element
If at some point in your system you need a library, another system or any element to connect, it should be easily assembled and modularized. In fact, for the system, this outer layer should be transparent.
Benefits of using a Clean Architecture
This technology is ideal when you have a long-term project. If you need it to last over time, to be able to test it with ease and high tolerance to change, and to minimize the impact of these changes, take advantage of the benefits of this kind of architecture:
1- Immediate implementation
You can implement it with any programming language, among which we cite: Java, .Net, Php, Node.js, etc.
2- Focus on the domain of the application
This means that the primary focus of the project is placed on the core and domain logic.
3- Possibility of changes
This architecture allows important changes to be made to the application, without major impacts:
- You could change the framework used if necessary, since everything is decoupled.
- You could also change the database you use or add another one if you need it.
4- Expected testing
You have the opportunity to test quickly and easily. You could perform unit tests of each of the layers and integration tests of the different layers with each other, being able to replace them with temporary objects that simulate their behavior in a simple way.
5- Optimum result
You will create a solid, quality and scalable product.
Now, if you want to make a minimum viable product (MVP), we recommend you to avoid these types of architecture. It will take too long, and it will require unnecessary cost and effort. If that MVP works and needs a more powerful and advanced development, the Clean Architecture can surely help you.
Clean Architecture and Domain-Driven Design
Clean Architectures fit very well with the Domain-Driven Design (DDD) approach. But what relationship do these clean architectures have with DDD?
Being an architecture that encourages our domain to be the core of all layers, and not coupled to anything external, they work perfectly together. We could say that DDD is based on a clean architecture as a central pillar in terms of architecture.
Now that you know when and why to use a Clean Architecture, you will be able to define if it is the best option for your project. At MyTaskPanel Consulting, we have quality professionals who have experience in the field and can be the technological support you need. Consult us without obligation here.
