Domain Driven Design: Layers
Creating applications that can handle very complex tasks requires separation of code by using directory structures, layers and boundaries. This is where the concept of a Layered Architecture comes in. Projects developed with the Domain Driven Design approach has the following layers: domain, application, infrastructure and user interface (UI).
The direction of the dependencies of the architecture points inwards. This means that the domain only depends on the code that is within the domain. The application can depend on the code that is within the domain and application, and the infrastructure code can depend on any code.
Let's try to understand the responsibility of each layer.
Understand basic concepts about Domain Driven Design, check our Introduction post.
The layer of business logic that should implement reality reflecting business processes. Since this layer is where abstractions are made, the design of interfaces are included in the domain layer. An important factor is that objects do not have too many technical details, such as a database connection (does not depend on how and where the objects are stored).
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. Each business model should have a clearly defined Bounded Context.
The application layer is responsible for creation and retrieval of domain objects, as well as calling their methods to satisfy user commands. It is the layer where business process flows are handled, execution of work commands and reactions to domain events are coded.
The application layer could also be seen as the service layer of your application. It can contain service classes that help with executing business rules on aggregates in your domain layer. It will load an aggregate from the domain repository, run an operation on the aggregate, and if the operation was successful, persist the aggregate again. The application layer can also handle the collecting and dispatching of domain events so other systems can listen in on the changes that have happened in your domain.
The infrastructure layer is responsible for communication with external websites, access to data (persistence storage) or to other resources. This layer will be the layer that accesses external services such as database, messaging systems and email services. The interface designed in the domain layer and used in the application layer will be implemented in this layer and gain an identity. Pieces of code that will be executed to communicate with the outside world such as network and file system are located in this layer.
This layer is the part where interaction with external world happens. It ca be used to implement controllers that handle incoming HTTP requests.
Please remember that there is no single way to design an application architecture. These principles certainly help but feel free to adjust them when it better fits your needs.
To be continued...