Eric Evans in the book DDD: Tackling Complexity in the Heart of Software presents a model characteristic for Domain Driven Design, which consists of layers: User Interface, Application, Domain and Infrastructure.
Domain layer
Domain layer is a layer of business logic that should implement reality-reflecting business processes. An important factor is that objects of the same level do not have too many technical details, such as a database connection. Thanks to this action you can easily test the operation of the domain application. The business domain model should be written using the “ubiquitous language”, which should be understandable for both those who know technical vocabulary and those who do not know it. By using a clear and understandable representation of the business model, new employees in a given project can be easily implemented. In a transparent form, we can also talk about the details of the application with non-technical people. Each business model should have a clearly defined Bounded Context.
Infrastructure layer
The infrastructure layer supports communication between layers. It is responsible for communication with external websites, access to data (persistance storage) or to other resources, e.g. rabbitmq, elasticsearch etc.
Application Layer
Provides communication with Domain Layer. Due to the fact that domain objects cannot leak outside of the domain area, domain objects created at the DL level are wrapped in DTO (Data Transfer Object) and in this form returns them to the UI layer.
User Interface layer
The presentation layer is responsible for the presentation of data, data can be presented in the form of JSON, or in various layouts using HTML, CSS, JS.
Persistence ignorance
Business logic should be implemented so that the domain layer does not depend on how and where the objects are stored. Layers of architecture: domain, infrastructure and presentation, which are responsible for separating functionality, help to maintain this principle.
