Hexagonal architecture - josuamanuel/softwareDevelopmentPrinciples GitHub Wiki
Notes:
Ports vs Adapters:
- Adapters are outside of the Application.
- Ports are the definition of each comunnication that goes: from out->inside the app (in green: driving adapters: ex: a route in express)... and from inside the app to out (in orange: driven adapters: ex: a http fetch).
- Application layer are the Controllers and services. The handlers of the ports above.
The main difference between ports and adapters are:
- Ports are part of the application (microservice).
- Adapters are outside (in the infraestructure)
- Ports are defined in the technology of the Application (microservice). If the microservice is a springboot Rest api, we expect a client to invoke the port using this tecnology. An adapter is external to the microservice and allows to convert a port into multiple infra tecnologies. Examples: 1) We could convert a response http from a port into a SMS or email server call inside of the adapter. 1) Apollo graphql server that receives graphQl queries and invoke REST ports.
- Ports (information transformation) As technology is fixed for ports... A port is identified by the information in and out. Ex: Giving a customer, return all their contracts.
- Adapters (technology adapters) are more concern to transform between protocols, keeping the business information the same. Ex: Giving a graphQl query, trigger different Rest end points.
this usually respresents a a spring boot microservice in most of the organizations.
Infraestructure:
- The external part is Infraestructure: API gategways, Command query bus, Web browser, Databases, Mobile App.
Most organizations define this as an API gateway, Bridge, Mobile app.
- Adapters: Adapters can allow us to connect any external system to the Application by implementing an adapter that is able to bridge between both techonologies (the external system vs the application).
Application:
These are the use cases. These are the processes that can be triggered in our Application Core by one or several User Interfaces in our application. Application is developed using a technology (spring boot rest api, SOAP api, socket API). The Application can be deployed by creating a packaged and deliver it in a container and then by plugging multiple external adapters to it.
Is composed: /* Ports:/ Translate the framework technology into Application services pure functional calls. Ports are still contaminated by ORM respositories (that autoimplement CRUD by using ORM clases). Ports are in charge of the delivery mechanism.
/* Application service:/ This contains the Use case. For example: We need to register a new customer. Register a new customer will require to: • Check if we find a customer that looks the same. • Validate address • Validate if customer is not in a terrorist list.
Use cases usually orquestrates calls to different domains.
/* Domain Layer:/ Further inwards, we have the Domain Layer. The objects in this layer contain the data and the logic to manipulate that data, that is specific to the Domain itself and it’s independent of the business processes that trigger that logic, they are independent and completely unaware of the Application Layer.
We can have two layers in the domain:
- Domain model: basic entities: customer, account.
- Domain services: Services that operates in several tables of the same domain. For example: newTransaction -> could create a new record in accountTransactionsTable and update the accountBalanceTable