Please enable JavaScript.
Coggle requires JavaScript to display documents.
ports & adapters - Coggle Diagram
ports & adapters
adapter
Secondary Adapters
The secondary or Driven Adapters represent the connection to your back-end databases, external libraries, mail API’s, etc. These adapters react to actions initiated by the primary adapters. The secondary adapters are implementations of the outbound port, which in return depend on interfaces of these external libraries and tools and transform application calls to fit their API, so the core application can use these without being coupled to them.
On the right side, the adapter is the concrete implementation of the port and is injected in our business logic although our business logic only knows about the interface. On this side, the port belongs inside the application, but its concrete implementation belongs outside and it wraps around some external tool.
Primary Adapters
The primary or Driving Adapters represents the UI. This can be our API controllers, Web controllers and views. They are called driving adapters because they drive the application, and start actions in the core application. These adapters can use the inbound ports (interfaces) provided by the core application. The controllers then depends on these interfaces of the core business logic.
On the left side, the adapter depends on the port and gets injected a concrete implementation of the port, which contains the use case. On this side, both the port and its concrete implementation (the use case) belong inside the application;
For example, an adapter implements an interface A and gets injected an interface B. When the adapter is instantiated it gets injected in its constructor an object that implements interface B. This adapter is then injected wherever interface A is needed and receives method requests that it transforms and proxies to the inner object that implements interface B.
-
The adapters are the ones that effectively implement the code that will allow the business logic to communicate with a specific tool and vice-versa.
In short, the adapter transform an interface into another.
You need to understand that there are 2 kind of adapters. Based on this the transformation itself is different.
ports
A port is a consumer agnostic entry and exit point to/from the application. In many languages, it will be an interface. For example, it can be an interface used to perform searches in a search engine.
Adapters, however, are not randomly created. They are created to fit a very specific entry point to the Application Core, a Port. A port is nothing more than a specification of how the tool can use the application core, or how it is used by the Application Core (mentioning the in and out ports here)
It’s important to note that the Ports (Interfaces) belong inside the business logic, while the adapters belong outside. For this pattern to work as it should, it is of utmost importance that the Ports are created to fit the Application Core needs and not simply mimic the tools APIs.
Alternatively, a Port can be a Command Bus or Query Bus interface. In this case, a concrete implementation of the Command or Query Bus is injected into the Controller, who then constructs a Command or Query and passes it to the relevant Bus.
An outbound port define the core’s view of the outside world. This is the interface the core needs to communicate with the outside world.
You can see a port like a gateway. It allows the entry or exiting of data to and from the application. In code, this is what we call an interface. Ports exist in 2 types. You have the inbound and outbound ports.
layers
The application core itself can be constructed using a Layered Architecture. Most of the time you will see both these architectures combined, and then just be called Hexagonal Architecture.
There are no layers. You have the application, the ports, and the adapters. The ports belong to the application, they are the API/SPI of the application. Adapters are outside the application, and each one depends on a port of the application.
-
goals
The application itself should never have any knowledge about who is sending or receiving the input and output. This allows the system to be secured against the evolution of technology and business requirements. You don’t want that an external system you use, to become obsolete. And then be completely coupled to it.
Ports & Adapters Architecture has only one goal: isolate the business logic from the delivery mechanisms and tools used by the system.
Ports and Adapters or also known as Hexagonal Architecture, is a popular architecture invented by Alistair Cockburn in 2005.
The confusion some people have is that when implementing the hexagonal architecture, most of the people don't physically put every adapter in an artifact, but they put all together into one artifact (like the infrastructure layer). And also they make depend on the adapters on the whole app, not just the port they use. So it would be an Onion in fact.
Implementing hexagonal right should separate adapters from each other, and every adapter should depend just on the port it uses/implements (depending on whether the port is a driver or driven).
What Alistair call application is not the DDD application layer, is the business logic as a whole, the hexagon, decoupled from technology. If you want a comparison with DDD layers, the hexagon would have to be splitted in two layers: application and domain. The ddd infrastructure layer would be the adapters outside the hexagon.