adjust text
This commit is contained in:
@@ -22,13 +22,12 @@ In short here is how we often layer such applications:
|
||||
* Contains the Applications 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
|
||||
* Interfaces:
|
||||
* set of adapters that convert data from the format most convenient for the use cases to the format most convenient for some external agency/access
|
||||
* 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
|
||||
* e.g. (Web) Controllers / DTOs for handling forms etc
|
||||
* Infrastructure:
|
||||
* This layer is where all the details go. The Web is a detail. The database is a detail. We keep these things on the outside where they can do little harm.
|
||||
* This is where you can use frameworks and tools such as the RDB Mappers etc.
|
||||
* communication details with other external systems (and its DataTransferObjects and Mappers)
|
||||
* 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..)
|
||||
* 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)
|
||||
|
||||
This 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.
|
||||
Reference in New Issue
Block a user