Sample code .NET

Layers

Domain

Entity

Value Object

Aggregate

Repository

Domain Service

Domain Event

Specification

Application

Application Service

DTO

Unit Of Work

Struct of code with C#

Sample Struct of code with Clean Architecture

Layers

Domain

• Domain: is the essential domain layer that contains all the building blocks (entities, value objects, domain services, specifications, repository interfaces, etc.) introduced before.

• Domain.Shared: is a thin project that contains some types those belong to the Domain Layer, but shared with all other layers. For example, it may contain some constants and enums related to the Domain Objects but need to be reused by other layers.

Application

• Application.Contracts: contains the application service interfaces and the DTOs used by these interfaces. This project can be shared by the client applications (including the UI).

• Application: is the essential application layer that implements the interfaces defined in the Contracts project.

Presentation

• Web: is an ASP.NET Core MVC / Razor Pages application for this example. This is the only executable application that serves the application and the APIs.

Infrastructure

In a DDD implementation, you may have a single Infrastructure project to implement all the abstractions and integrations, or you may have different projects for each dependency. We suggest a balanced approach; Create separate projects for main infrastructure dependencies (like Entity Framework Core) and a common infrastructure project for other infrastructure. ABP's startup solution has two projects for the Entity Framework Core integration; EntityFrameworkCore, EntityFrameworkCore.Migration (code first).

Dependencies of the Projects in the Solution

The projects have been explained before. Now, we can explain the reasons of the dependencies;

● Domain.Shared is the project that all other projects directly or indirectly depend on. So, all the types in this project are available to all projects.

● Domain only depends on the Domain.Shared because it is already a (shared) part of the domain. For example, an IssueType enum in the Domain.Shared can be used by an Issue entity in the Domain project.

● Application.Contracts depends on the Domain.Shared. In this way, you can reuse these types in the DTOs. For example, the same IssueType enum in the Domain.Shared can be used by a CreateIssueDto as a property. 20 Implementing Domain Driven Design

● Application depends on the Application.Contracts since it implements the Application Service interfaces and uses the DTOs inside it. It also depends on the Domain since the Application Services are implemented using the Domain Objects defined inside it.

● EntityFrameworkCore depends on the Domain since it maps the Domain Objects (entities and value types) to database tables (as it is an ORM) and implements the repository interfaces defined in the Domain.

● HttpApi depends on the Application.Contracts since the Controllers inside it inject and use the Application Service interfaces as explained before.

● HttpApi.Client depends on the Application.Contracts since it can consume the Application Services as explained before.

● Web depends on the HttpApi since it serves the HTTP APIs defined inside it. Also, in this way, it indirectly depends on the Application.Contracts project to consume the Application Services in the Pages/Components