In software development, we often seek to solve problems of scalability, maintainability and testability of code. This is where Hexagonal Architecture, also called "Ports and Adapters", comes into play.
The idea of this approach developed by Alistair Cockburn is that the business domain (the heart of your application) is isolated from the rest of the system and can be used independently of external technologies (framework, database, UI, external APIs ).
Come on, let's dive into the fundamental concepts of Hexagonal Architecture and see together how it can transform the way you design your code! ?
Hexagonal Architecture is a way of structuring an application so that it is independent of external details. It emphasizes the separation of concerns by dividing the application into several distinct layers.
The goal is to make the application independent of specific technologies, by organizing the interactions between the heart of the application (business logic) and the outside world (database, user interfaces, API, frameworks, etc. ), all this via Ports and Adapters.
Imagine your application as a hexagon with the domain (business logic) in the center. This core business should not be directly linked to implementation details (like Symfony, Doctrine, a third-party API, etc.). To achieve this, it will be necessary to create interfaces called Ports, and these interfaces will be implemented by Adapters, which take care of communication with external services.
? Ports: in other words, the interfaces through which the outside world can interact with the business core. Ports are the entry or exit points of the application (API, HTTP requests, CLI commands, etc.).
? Adapters: adapters are the concrete implementations of these interfaces. They translate external requests or responses into actions understandable by business logic. This includes interactions with databases, frameworks, APIs, etc.
To understand better, we will use a simple example in Symfony. Let's imagine that your application must allow users to place orders, and that it must interact with a database to store these orders.
Well, look at how you could structure your application according to the hexagonal architecture. ?
This is the core of your application, the part that has no external dependencies. This is where the business logic lies, like creating an order, validating its data, etc.
Here, the Order class represents the basic model of an order. You will notice that this class knows nothing about how it will be stored, or where the data comes from.
Ports define the interfaces that the adapters will have to implement so that the business logic can work. They can be entry points into the system (like HTTP requests) or exit points (like calls to the database).
The OrderRepositoryInterface interface will serve as the output port. It just defines the methods that the business logic needs to interact with the database. The domain does not know how this data will be saved.
The Adapter is quite simply the concrete implementation of a Port. The Adapter will allow you to translate:
Adapt here translates the call to OrderRepositoryInterface into an interaction with Doctrine (database management library) but your business logic has no idea that Doctrine is used.
The controller will act as a entry point for our application. It is he who interacts with the user via HTTP requests, then delegates tasks to the domain via Ports and Adapters.
Here you can see that the controller only knows the OrderRepositoryInterface interface and not the concrete implementation. This makes the code testable, extensible, and independent of external frameworks and technologies (Symfony, Doctrine, etc.).
By separating your business logic from external implementations (database, HTTP, external APIs), you make your code more flexible. Changing database or framework becomes simpler and less risky.
As the business logic is not tied to external elements, you can easily mock or replace the adapters in your tests.
With this clear separation, it is easier to add new features, modify behaviors or reuse certain components without affecting the business logic.
You can reuse the same core business with different types of adapters. For example, the same business logic can be used for a web application, a REST API or even a command line interface.
Even though the hexagonal architecture is powerful, structuring your application this way can be a bit overkill, especially for small projects. For small applications, the hexagonal architecture can add unnecessary complexity, because decoupling everything is not always necessary.
The above is the detailed content of Discovery of Hexagonal Architecture: for robust and scalable code. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
