Update ports-and-adapters.md
This commit is contained in:
committed by
GitHub
parent
b1b41d4f14
commit
706aa0a88c
@@ -5,29 +5,29 @@ quadrant: methods-and-patterns
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
Ports and Adapters is an architecture or layering approach for software design. As with other layering approaches it seperates different concerns in different layers, where dependencies are only allowed to be from the outside to the inside.
|
Ports and Adapters is an architecture or layering approach for software design. As with other layering approaches, it seperates different concerns in different layers, where dependencies are only allowed from the outside to the inside.
|
||||||
|
|
||||||
We use "ports and adapters" with success for (bigger) applications which contains certain business logic and/or provides several ways to access the services.
|
We use "ports and adapters" with success for (larger) applications, which contain certain business logic and/or provide several ways to access the services.
|
||||||
We often use it hand in hands with domain driven design. In comparison with other layering patterns (e.g. layered architecture) it allows to have a true technologie free core (domain) model, because with the concept of "secondary ports" (=interfaces) it inverts the control and allows outer layers to provide adapters (=implementations of the defined interface).
|
We often use the approach hand-in-hand with Domain Driven Design. In comparison with other layering patterns (e.g. layered architecture) it allows you to have a true technology-free core (domain) model. Why? Because, with the concept of "secondary ports" (=interfaces), it inverts the control and allows outer layers to provide adapters (=implementations of the defined interface).
|
||||||
It also defines clear boundaries for where to put what logic of your application.
|
It also defines clear boundaries regarding where to put what logic of your application.
|
||||||
|
|
||||||
You can find more about the details and its origins in famous blog posts like [The Clean Architecture](https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html) or [Hexagonal architecture](http://alistair.cockburn.us/Hexagonal+architecture)
|
You can find out more about the details and its origins in well-known blog posts such as [The Clean Architecture](https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html) or [Hexagonal architecture](http://alistair.cockburn.us/Hexagonal+architecture)
|
||||||
|
|
||||||
In short here is how we often layer such applications:
|
In short, here is how we often layer such applications:
|
||||||
* Domain:
|
* Domain:
|
||||||
* Is the inner layer and contains the technology free domain model
|
* Is the inner layer and contains the technology-free domain model
|
||||||
* Often using building blocks from domain driven design
|
* Often uses building blocks from Domain Driven Design
|
||||||
* It defines primary and secondary ports. (E.g. a secondary port is in "interface" that need to be implemented in the infrastructure layer.)
|
* It defines primary and secondary ports. (E.g. a secondary port is in "interface" that needs to be implemented in the infrastructure layer.)
|
||||||
* Application:
|
* Application:
|
||||||
* Contains the Applications API and Services, that are developed around the use cases in the application requirements.
|
* Contains the Application's API and Services, that are developed around the use cases in the application requirements.
|
||||||
* This use cases orchestrate the flow of data to and from the domain
|
* These use cases orchestrate the flow of data to and from the domain
|
||||||
* Interfaces:
|
* Interfaces:
|
||||||
* Contains everything required to convert data from the format most convenient for the use cases (e.g. in the application layer) to the format required for some external agency/access
|
* Contain everything required to convert data from the format most-convenient for the use cases (e.g. in the application layer) to the format required for external agency/access
|
||||||
* e.g. (Web) Controllers / DTOs for handling forms etc
|
* e.g. (Web) Controllers / DTOs for handling forms, etc.
|
||||||
* Infrastructure:
|
* Infrastructure:
|
||||||
* This layer is where all the (technical) details live. (The database and persitence is a detail, the communication format and mappings with external services is a detail, etc..)
|
* This layer is where all the (technical) details live. (The database and persistence is a detail, the communication format and mappings with external services is a detail, etc.)
|
||||||
* In this layer you typically have adapters for the secondary ports that have been defined in the layers below. (e.g. an Implementation of a Repository interface from the Domain layer)
|
* In this layer you typically have adapters for the secondary ports that have been defined in the layers below. (e.g. an Implementation of a Repository interface from the Domain layer)
|
||||||
|
|
||||||
These layers belong to every bounded context (modules) inside the application.
|
These layers belong to every bounded context (modules) inside the application.
|
||||||
|
|
||||||
So if you are searching for a potential timeless architecture for your critical application? Try to implement a potent technology free domain model in the core layer and use ports and adapters to layer your application.
|
Are you searching for a potential timeless architecture for your critical application? Try implementing a potent technology-free domain model in the core layer and use ports and adapters to layer your application.
|
||||||
|
|||||||
Reference in New Issue
Block a user