Architectures, Software
Exploring clean architectures
For a long time, different architectures have existed for software development. Some are easy to implement for small, short-term projects. However, others provide maintainability for large, long-term projects.
Architectures aim to improve how we work with software so that it is maintainable over time while minimizing costs. But then, what are clean architectures? They are defined as a set of software design principles that can be applied to any technology.
Layered architecture
Currently, one of the bestknown and most widely used architectures is the layered architecture, which is typically divided into three distinct parts:
• Controller: This layer acts as the access point to our logic, usually via HTTP in an API.
• Services: This layer houses our business logic and processes.
• Persistence: This layer handles data storage and is typically closely linked to the services.
These architectures are maintainable, clean, and evolve rapidly at the beginning of a project’s lifecycle. They work very well for small projects, but become difficult to manage as the project grows. This evolution can even lead to them becoming inflexible or difficult to test because the layers quickly become intertwined. Therefore, it’s essential to thoroughly analyze the project and understand when to use them.
Clean architecture
There is another type of architecture based on software design principles that helps keep project components simple, allows for openness to change, and facilitates easy testing. These are known as clean architectures. They can be applied to any technology and help decouple software components that evolve at different speeds.
It is important to emphasize the flexibility and adaptability they bring to software systems because systems must be considered living entities that are constantly evolving. A clean architecture is based, among other design principles, on the SOLID principles to keep all objectives aligned and create a structure that is easily understandable and testable. Applying SOLID principles to any project will inevitably lead you to a clean architecture, although the implementation may differ from project to project. Let’s explore these principles in more detail below.
Solid Principles
S (SRP) Single Responsibility Principle: states that a class/function should only have one reason to change.
O (OCP) Open/Close Principle: open to extension, but closed to modification.
L (LSP) Liskov Substitution Principle: an object should be able to be substituted by subtypes of itself without altering the base class.
I (ISP) Interface Segregation Principle: several specific interfaces are better than one general-purpose interface.
D (DIP) Dependency Inversion Principle: helps ensure that the application’s business processes are not dependent on the infrastructure (databases, integrations, etc.).
Hexagonal architecture
An example of a clean architecture is hexagonal architecture, also known as ports and adapters architecture, but there are other noteworthy ones such as onion architecture. Hexagonal architecture clearly separates responsibilities, is open to extensibility, and is easily testable. It clearly differentiates the domain (or model) of business rules from the infrastructure. With this type of architecture, we can lower the cost of long-term projects because it is open to changes.
It is called ports and adapters because they are the pillars for implementing and connecting the external layers with our business. We use ports to define the contract between the business and the infrastructure (frameworks, databases, etc.), and adapters are responsible for implementing those ports or contracts, adapting them to the external specification (for example, we could have one adapter implemented for DB2 and another for MongoDB, but both would comply with the contract specification).
How can we help you at ARENA?
Introducing this type of architecture is always beneficial, allowing a project to evolve without fear of changes to existing functionality. At ARENA, we are implementing hexagonal architecture in our projects as a foundation for robust and high-quality code. This allows us to provide greater robustness and flexibility for changes in our projects, which translates into greater trust from our clients.
The main advantage of implementing this type of architecture is creating verticals that adapt to each client’s business, resulting in reusable components and lower project costs.
As you can see, this type of architecture has many advantages, but it doesn’t always have to be the chosen option. It’s important to evaluate the project, understand its scope, and have a very clear objective in order to implement one architecture or another. That’s why at ARENA we use our own methodology that always delivers excellent results: listen, understand, propose, and execute.
