# 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”>
 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.