Domain Driven Design (edit)
Domain Driven Design Implement - @manhng
Open Source ASP.NET MVC Enterprise eCommerce Shopping Cart Solution
Open Source ASP.NET Core Enterprise eCommerce Shopping Cart Solution
Onion Architecture with .NET 5/.NET Core and CQRS/Event Sourcing following a DDD approach
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/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
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
Flutter Architecture inspired by Domain Driven Design, Onion and Clean Architecture
Example using DOTNET for Onion Architecture with DDD & Tooling (FluentValidation, MassTransit, RabbitMQ, MediatR). Using best practices & common best patterns
Blog series supplementary domain-driven design C# repository that (hopefully) actually makes sense
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
- EntityFramework as the Repository Pattern in the Infrastructure Layer
- Code First: EF Migrations to create/update database
- Fluent API
- AutoMapper to map the View Model Entities to the Domain Entities and vice-versa.
- Ninject MVC5 to the container of MVC’s Dependency Injector
- SQL Server Local as the database
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.
- Ensure that the software architecture is designed separately in well-defined layers
- As a SOLID expert, never reference a layer directly. Always use abstractions.
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!