# Introduction
From the blog post at https://medium.com/@jpdeffo/domain-driven-design-ddd-in-microservice-architecture-for-nutshell-19c7c579009a and code at https://github.com/Defcoq/DDD
I have learned how to architect a .NET Core project by using DDD principals.
The main thing you will have to realize, when you come from a layered architecture, is that the logical flow of data, does not correspond with the project references in Visual Studio.
# Logical dataflow
Controllers (MyApp.Web.csproj) => Domain Services (MyApp.Domain.csproj) => Persistence services (MyApp.Persistence.csproj)
Controller data flows
– On a HTTP GET a .NET controller will,
OPTIONAL – Receive primitive types or data transfer objects (DTO) from the client
OPTIONAL – Map data transfer objects (DTO) to domain models
Call domain service(s) by using DI
Receive domain models
Map domain models to data transfer objects (DTO)
Return data transfer objects (DTO) to the client.
– On a HTTP POST a .NET controller will,
OPTIONAL – Receive primitive types or data transfer objects (DTO) from the client
OPTIONAL – Map data transfer objects (DTO) to domain models
Call domain service(s) by using DI
OPTIONAL – Receive domain models
OPTIONAL – Map domain models to data transfer objects (DTO)
OPTIONAL – Return data transfer objects (DTO) to the client.
Domain Service data flows
– Receive primitive types or domain models
– Act on domain models
– OPTIONAL – Call persistence services with primitive types or domain models, by using DI
– OPTIONAL – Receive primitive types or domain models
– OPTIONAL – Return primitive types or domain models
Persistence services data flows
– OPTIONAL – Receive primitive types or domain models
– OPTIONAL – Map primitive types or domain models to persistence models
– OPTIONAL – Act on persistence models
– Call an ORM or other persistence layer framework
– OPTIONAL – Map persistence models to primitive types or domain models
– OPTIONAL – Return primitive types or domain models
# Project references
Controllers (MyApp.Web.csproj) => Persistence services (MyApp.Persistence.csproj) => Domain Services (MyApp.Domain.csproj) => MyApp.Infrastructure.csproj (Logging, Monitoring, Security, and other code that can be reused between projects).
By putting the Interfaces for the ‘persistence services’ inside the ‘domain’ project, the implementation inside the ‘persistence’ project and referencing the ‘domain’ project from the ‘persistence’ project and using DI inside the ‘web’ project sta.
We can make the ‘domain’ project totaly independent from other custom assemblies and make the controllers only use types from the ‘domain’ project.
Note: All data coming from the ‘persistence’ project and all data send to the ‘persistence’ project, should be primitive types or ‘domain’ models.
It is a good practice to make the Entity Framework types internal, so they cannot be accidentaly used outside the MyApp.Persistence.dll.
In some cases, you will have multiple persistence projects, e.g. when you must interact with a database and other micro services.
– MyApp.Persistence.Database.csproj
– MyApp.Persistence.MyOtherMicroService.csproj
# Other Resources
A good description of passing data between layers and how you should do that, is described here:
https://stackoverflow.com/questions/2330535/why-its-not-a-good-idea-to-pass-entities-as-models-in-mvc
EF and DDD
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/infrastructure-persistence-layer-implementation-entity-framework-core
<
p style=”background: #1e1e1e”>