Hexagonal architecture is replacing the layered style
Hexagonal architecture is an architectural pattern for designing software applications. Its popularity has grown in recent years as an alternative to traditional layered architecture.
This Architectural Pattern SOC (separation of concerns) The principle of decomposing our components into layers, each with a different responsibility. Typically, there are 3 layers:
- Presentation layer, which contains the user interface.
- Business layer or domain layer, which contains business logic.
- The persistence layer, which handles database operations.
While implementing this architectural pattern, we are faced with dependencies between layers, i.e. each layer immediately depends on the layer below. This model fails to show that we can interact with more than one database or not interact with any database at all. Furthermore, the presentation layer does not take into account that there may be more than one way for a user to interact with our application.
This model places all business logic at the core of the application, abstracting any kind of external dependencies. This separation makes the logic a lot easier to test and maintain.
Instead of a presentation layer, the application now has one or more input adapters that handle user requests. Similarly, instead of the persistence layer, we now have one or more output adapters that invoke external applications or services, such as a file store in Amazon S3, an email service such as SendGrid, or, more commonly, a database.
The business core consists of one or more ports. A port defines a set of operations that allow the core to interact with the adapter, and therefore, what is outside the application. Just as we have two types of adapters, input and output, there are an input port and an output port. Input ports are APIs exposed by the core to be accessed by external applications, while output ports are interfaces that allow the core to consume external services.
An input adapter handles requests from the outside world by implementing an input port. An example of this would be a Spring controller implementing the REST API or a gRPC server.
An output adapter implements an output port that handles requests from the business core by implementing an external application or service. Some examples are a DAO (Data Access Object) class that performs database operations, or a Spring component that consumes an email service.
So far we have seen concepts related to hexagonal architecture. Now, let’s put the theory into practice and build a Spring application using Kotlin.
To start, I personally like to split the project into three main packages:
core“Package, which includes components related to the core business.
ports“The package, which contains input and output components that communicate the business core to the outside world.
config“Package, for all the configuration needed to launch the application and handle its internal behavior.
here is ours
Article company. Note that this is in plain Kotlin (or Java), but represents the business unit as a whole.
here it is
ArticleRepository The interface, which allows the business core to communicate with external services.
here it is
ArticleService Interface, which allows external applications to communicate with the business core.
usecase the packet,
ArticleServiceImpl Class spread out
ArticleService and contains the actual business logic.
Output port for database adapter
ports/output/jpa The package holds the components for maintaining the data in the database.
here it is
ArticleJpa Classes based on the core unit.
here it is
ArticleJpaRepository class that extends
JpaRepository From Spring JPA Library.
ArticleDao class extension
ArticleRepositoryAllows the business core to fetch and maintain data.
Input port for REST adapter
ports/inputs/rs The rest of the package contains controllers that expose endpoints to be consumed by external applications.
When engineering software, a set of basic requirements are present, known as quality-to-service requirements. These requirements define some of the trade-offs that we must address in the process of building quality software, such as scalability, reliability, maintainability, testability, and deployment.
Architecture matters because, if we are smart enough when choosing, the right architectural pattern for our projects will help our software meet the expected quality and, perhaps, spare us some headaches.
Example code is available at GitHub,
#Hexagonal #architecture #spring #Hexagonal #architecture #replacing #Jonathan #Manera #July