Categories: ASP.NET CoreDotNet5Microservices

Microservices – Domain-driven design(DDD)

Domain-driven design (DDD) is a software design approach focusing on modelling software to match a domain according to input from that domain’s experts
Wiki

Domain-driven design(DDD) is a fundamental software strategy in the standard web application, which focuses on modeling software to match a domain according to input from that domain’s experts.

Domain-driven design is predicated on the following goals:

placing the project’s primary focus on the core domain and domain logic;
basing the complex design on a model of the domain;
Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.

This idea starts point from Eric Evans’s books. The DDD’s goals explain that when the program encounters complex business logic situations, the developers should use this strategy in the standard web application. It doesn’t mean the developer faces the lightless business logic situation and doesn’t use it in the modern web application. Senior developers, system design people, and other IT people should be considered one very important factor, that is the horizontal software development. People will say, ” I can’t ensure the future of the software. I only can focus on the now requests and develop the web application.” From the author’s viewpoint, I will give them an un-good evaluation because the product is your design and making. You can’t say, “This software performance just that is. It could not improve.” Remember one thing if the SDK can support your web application and doesn’t have LST problems, the developer should do your best. Anyone enterprise would not give the IT team a second choice again because everyone huge system development must spend a lot of cost from the enterprise viewpoint, such as the infrastructure, the developer salary, the hardware cost and etc.

Three layers in DDD microservices

Most enterprise applications will be designed the multiple layers, including the business and the technical layers. This article will come back to the initial point to explain the DDD in microservices. The microservices web application of three layers will be divided into three layers: the application layers, the domain model layers, and the infrastructure layers.

Fig 1 DDD in microservices

Application layers in DDD microservices

The application layer of the modern web application focuses on the software job that is supported to do and directs the expressive domain object to work out problems. This layer’s task is responsible for the business or is necessary for interaction with the application layers of other systems. This layer should be kept thin and doesn’t contain the business rules or knowledge but only coordinates tasks and delegates work to collaborations of domain objects in the next layer.

A microservice’s application layer in .NET is commonly coded as an ASP.NET Core/.NET 5 Web API project, which implements the microservice’s interaction, remote network access, and the external Web APIs used from the UI or client apps. This layer includes queries using a CQRS approach, commands accepted by the microservice, and even the event-driven communication between microservices(integration events). The microservice’s application layer with the modern web application’s application layer has different methods leading to the same result. Still, a few different parts must only coordinate tasks and not hold or define any domain state(domain model). It delegates the execution of business rules to the domain model class object themselves(aggregate roots and domain entities) that will ultimately update the data within those domain entities.

Basically, the application logic is where the developers implement all use cases that depend on a given front-end.

The application layer goal is that the domain logic in the domain model layer, its invariants, the data model, and related business rules must be completely independent of the presentation and application layers. Most of all, the domain model layer must not directly depend on any infrastructure framework.

Note: The core project of my sample project is the domain model layer of the DDD.

Domain model layer in DDD microservices

Domain model layer – Responsible for representing business concepts, information about the business situation, and business rules. State that reflects the business situation can controller used here, even though the technical detail of sorting it is delegated to the infrastructure. The domain model layer is the business software heart, which follows the “Persistence Ignorance” and the “Infrastructure Ignorance” principles must completely ignore data persistence details. The infrastructure layers should perform these persistence tasks. Therefore, the domain model layers don’t take direct dependencies on the infrastructure layers, which means that the essential rules are that the web application’s domain model entity class should be POCOs (Plain old CLR objects), so the domain entities don’t have any direct dependency on any data access infrastructure framework like Entity Framework(EF) or NHibernate and don’t derive from or implement any type defined in any infrastructure framework.

In recent years ORM framework, like the Entity framework Core/Entity framework, allows this approach to the web application domain model class not couple to the infrastructure. Having POCO entities isn’t always possible when using certain NoSQL databases and frameworks; even when it is essential to follow the “Persistence Ignorance” principle for the web application Domain model, developers should not ignore persistence concerns. It is still essential to understand the physical data model and how it maps to the web application entity object model. Otherwise, you can create impossible designs. Therefore, this aspect doesn’t mean the web application can take a model designed for a relational database and directly move it to a NoSQL or document-oriented database. Most entity models might fit, but usually, it doesn’t. There are still constraints that the web application entity model must adhere to, based both on the storage technology and ORM technology.

Infrastructure layer in DDD microservices

The infrastructure layer is initially stored in the domain entity, which in memory is persisted in the database or another persistent store, according to the previously explained Persistence Ignorance and Infrastructure Ignorance principles. The infrastructure layer can’t contaminate the domain model layer(Core layers). The developers must keep the domain model entity class objects agnostic from the infrastructure and use them to persist data, such as EF, Dapper, and any other framework, which doesn’t mean hard dependencies on the frameworks. The domain model layer class library should have only itself domain code and just POCO entity class objects implementing the web application heart and wholly decoupled from infrastructure technologies.

Fig 2 DDD in microservices tree

Reference