As Tolkien wrote, “One Ring to rule them all, One Ring to find them, One Ring to bring them all and in the darkness bind them”. Software architecture arise when creating a project with the intention of addressing all current and anticipated code organization problems. However, some programmers tend to use the same architecture that worked for them in previous projects, assuming it will work in the current one, but that is not always correct.
I believe that one of the fundamental qualities of a good samurai developer is knowledge of different types of architectures and understanding when can or can’t be used.
Let’s explore some of the most common architectures today.
Layers
Ah, the old and reliable layered architecture. The fundamental idea is to divide the project into layers, each with a well-defined function. Different types of divisions can exist, but the most well-known pattern is as follows:
UI: The graphical interface, whether it’s a desktop or web interface, takes user input and presents application results.
Domain: The domain part contains all the business logic, including entities.
Infrastructure: This section handles external services and/or database management.
The main advantages are simplicity and clarity, at least in the early stages of a project. The problem arises when the project grows, as complexity requires modularizing each layer again to maintain organization.
Hexagonal
The Hexagonal architecture, also known as Ports and Adapters, organizes code in a way that isolates the application from external resources (databases and external services).
What are Ports in the Hexagonal architecture, and what do they do?
Ports are technology-agnostic abstractions that describe the interface through which an external entity can communicate with our application.
Ports also allow our application to communicate with external systems or services, such as databases, message brokers, APIs of other applications, etc.
What are Adapters in the Hexagonal architecture, and what do they do?
Adapters handle communication with the ports. They act as intermediaries between external systems and the ports. Their main function is to convert the calls received from an external system to the interface understood by the adapter and vice versa, converting the responses from the port to meet the interface expected by the external system.
Isolation in the Hexagonal systems
With adapters acting as intermediaries for external services and ports acting as intermediaries for application input and output, the application’s domain logic remains isolated from the rest of the entities. This facilitates the exchange of technologies. For example, if we want to replace the use of an SQL database with a NoSQL database, the application does not get affected as long as it adheres to the adapter and port interfaces.
Disadvantages of the Hexagonal
Requires a deep understanding of the domain and infrastructure to be able to create a good design of the components.
As the system grows, it becomes difficult to modify if the data structures and connections between components are not cohesive.
Microservices
This architecture organizes the application as a set of loosely coupled services that can be deployed independently and grouped by the functionality they provide.
One of the advantages of this component arrangement is the independence between services. Developers can develop each service using different technologies as long as they adhere to the communication protocol between services. They can update and exchange services without affecting other services.
Example of microservice architecture
Disadvantages of the microservice architecture
Testing becomes more complex as multiple services need to be tested to ensure correct functionality.
The developer need a thorough design is required to group components in a way that fully encapsulates the data they handle and allows communication with other services without exposing internal functionality.
Changes in requirements can make it challenging to place certain functionalities in a single service or make communication between services inefficient.
Maintaining consistency in an operation involving multiple services can be difficult.
Conclusions
The One Architecture is nothing more than a blend of different choices. Knowing how to apply the optimal architectural pattern to each problem grants you the power to govern each issue and bind them forever in darkness .
References:
http://www.javapractices.com/topic/TopicAction.do?Id=205
https://martinfowler.com/bliki/PresentationDomainDataLayering.html
https://martinfowler.com/articles/microservices.html
https://microservices.io/patterns/microservices.html
Be First to Comment