Domain Driven Design (edit)

Domain Driven Design Implement - @manhng

Open Source ASP.NET MVC Enterprise eCommerce Shopping Cart Solution

smartstore/SmartStoreNET: Open Source ASP.NET MVC Enterprise eCommerce Shopping Cart Solution (github.com)

Open Source ASP.NET Core Enterprise eCommerce Shopping Cart Solution

smartstore/Smartstore: Open Source ASP.NET Core Enterprise eCommerce Shopping Cart Solution (github.com)

Onion Architecture with .NET 5/.NET Core and CQRS/Event Sourcing following a DDD approach

pereiren/dotnet-template-onion: Onion Architecture with .NET 5/.NET Core and CQRS/Event Sourcing following a DDD approach (github.com)

Domain-Driven Design with Onion Architecture (infoq.com)

Onion Architecture Is Interesting - DZone Java

Domain Driven Design

A simple template for Onion Architecture with .NET 5 | by David Pereira | Medium

Clean architecture series— Part 1 | by David Pereira | Medium

Clean architecture series — Part 2 | by David Pereira | Medium

Clean architecture series — Part 3 | by David Pereira | Medium

Onion Architecture with .NET 5/.NET Core and CQRS/Event Sourcing following a DDD approach 

gtechsltn/dotnet-template-onion: Onion Architecture with .NET 5/.NET Core and CQRS/Event Sourcing following a DDD approach (github.com)

gtechsltn/Onion-DDD-Tooling-DotNET (github.com)

Domain Driven Design in ASP.NET MVC 5

Example using DOTNET for Onion Architecture with DDD & Tooling (FluentValidation, MassTransit, RabbitMQ, MediatR). Using best practices & common best patterns

  • ASP.NET MVC 5
  • Onion Architecture
  • Clean Code & Clean Architecture
  • Domain Driven Design (DDD)
  • FluentValidation
  • MediatR
  • Autofac Mvc5
  • Autofac.WebApi2

gtechsltn/Onion-DDD-Tooling-DotNET: Example using dotNET for Onion Architecture with DDD & Tooling (FluentValidation, MassTransit, RabbitMQ, MediatR). Using best practices & common best patterns (github.com)

DDD for dummies: #sqn #saidnooneever | by Aline Paulucci | Medium

Domain-Driven Design with ASP.NET MVC (slideshare.net)

Clean Architecture with .NET5, C#9 and React+Redux. Use cases as central organizing structure, completely testable, decoupled from frameworks

gtechsltn/clean-architecture-manga: Clean Architecture with .NET5, C#9 and React+Redux. Use cases as central organizing structure, completely testable, decoupled from frameworks (github.com)

Flutter Architecture inspired by Domain Driven Design, Onion and Clean Architecture

gtechsltn/flutter-architecture-ddd: Flutter Architecture inspired by Domain Driven Design, Onion and Clean Architecture (github.com)

Example using DOTNET for Onion Architecture with DDD & Tooling (FluentValidation, MassTransit, RabbitMQ, MediatR). Using best practices & common best patterns

gtechsltn/Onion-DDD-Tooling-DotNET: Example using dotNET for Onion Architecture with DDD & Tooling (FluentValidation, MassTransit, RabbitMQ, MediatR). Using best practices & common best patterns (github.com)

Blog series supplementary domain-driven design C# repository that (hopefully) actually makes sense

gtechsltn/Domain-Driven-Design-Example: Blog series supplementary domain-driven design C# repository that (hopefully) actually makes sense. (github.com)

Articles

Applied Domain-Driven Design (DDD), Part 1 - Basics

Applied Domain-Driven Design (DDD), Part 2 - Domain events

Applied Domain-Driven Design (DDD), Part 3 - Specification Pattern

Applied Domain-Driven Design (DDD), Part 4 - Infrastructure

Applied Domain-Driven Design (DDD), Part 5 - Domain Service

Applied Domain-Driven Design (DDD), Part 6 - Application Services

Applied Domain-Driven Design (DDD), Part 7 - Read Model Services

Applied Domain-Driven Design (DDD), My Top 5 Best Practices

Applied Domain-Driven Design (DDD), Event Logging & Sourcing For Auditing

Domain Driven Design in ASP.NET MVC 5

Before everything, let me explain what “sqn” means… In Brazil, SQN means “Só que não”, that in a poor translation means “But it’s not”, but is a lot more completed than that! It’s something like “no way” in an ironic way.

Going back to DDD, as I said in the last post DDD — a superficial view, it means “Domain Driven Design”.

I started to study it more deeply and I saw how complex and extended it is. It involves many concepts. It became impossible to understand DDD just in theory. (I have this problem at all… I really like to get my hands dirty…). So, I created a project, driven by this great guideline (unfortunately — or fortunately — the class is in Portuguese), and then I created my own guideline and structure.

Above is the structure of DDD.

And bellow is the structure of my understanding of the project.

The project DDD.Demo.AspNetMVC.Products is available at my GitHub account. I used:

  • Asp.Net MVC 5 as Presentation Layer

Baby steps:

1- To create the project/solution and the structural folders

2- Domain Layer: To create the domain entities

3- Infrastructure Layer: To build the Context/DbContext/DbSet

4- Presentation Layer: ConnectionString at the MVC Project (WebConfig)

5- In the Infra Layer, create a EntityConfig, that will be the map between the repository and the database.

6- Package Manage Console: Enable Migrations / Update-Database

7- Repositories Interfaces: Base (generic with standard CRUD’s calls) and Specific for each Domain Entity

8- Repositories implementations: Base(generic) and Specific

9- Domain Layer/Services interfaces: Base(generic) and Specific

10- Domain Layer/Services implementation: Base(generic) and Specific, using Dependency Injection of the repository’s interface inside the Constructor

11- Application Layer/Application interfaces: Base and Specifics

12- Application Layer/Application implementation: Base and Specifics (DI of the Service’s interfaces inside the Constructor)

13- Presentation Layer: to create the ViewModels based in the DomainEntities, using the AutoMapper to map both entities.

14- To create the MVC Controllers, and in this case a use of a container (Ninject) is necessary to inject the application’s interfaces.

15- To create the Views

Some points we should keep in mind when using DDD:

  • You must keep the persistence ignorance of the domain. Many layers can have the domain as reference, but the domain must not reference any other layer.

DDD is easier to understand when you start to see a real project being built from the scratch. I hope I could help you! :)

See you in the next post!