We have spent 14 articles introducing classic DDD concepts, architectures, and practices. In this article, we will do a complete summary and generate an Api interface document.

DDD solves several major problems of traditional development:

  • No design model describing requirements; Rather, it is expressed directly in the form of database tables, where requirements and design are disconnected.

  • The architecture of the code is also not aligned with the design and requirements.

  • Business logic mixed with technology; Business logic may invoke data access directly, thus mixing business logic with data access techniques.

  • Development has no sense of hierarchy and rhythm; The system does not have a uniform constraint, the developer does not have a uniform rhythm, this is mainly reflected in arbitrary coding.

  • Bug location difficulty: When abnormal business behavior occurs in the system, it is impossible to quickly and accurately locate the problem location, because the code placement of different developers in the system is arbitrary.

  • Slow response to requirements change: In large systems or products, when functions need to be added or existing functions modified, due to the randomness of the code architecture, it may appear that the changed functions may affect other functions, resulting in system instability

Domain – driven Design (DDD) is the way to solve software design and development problems. The DDD approach solves these problems flexibly and provides a good design, architecture, and quality code.

Ii.DDD solution:

The DDD method first needs to analyze the requirements and form a domain model to reflect the requirements. Domain model is the common understanding of classes, class properties, relationships between classes and so on. Of course, in DDD, there are some patterns of guidance for classes, their properties, relationships between classes, and so on, in order to better reflect the domain model requirements. For example, the properties of a class may be general properties or value objects; For example, whether the related classes represent a whole concept, have the same life cycle, need unified persistence, etc. Therefore, in addition to running through requirements, our domain model should also consider the application of concepts such as aggregation root, entity, value object and aggregation, so that the design of the domain model can better reflect requirements and better correspond the design into binding code. DDD also provides a number of patterns that tell us how to write code for our design, allowing us to really map our code to the design; How to separate business logic from persistence mechanism; How to better architecture design.

1.DDD can cope with complexity System complexity is mainly reflected in three aspects. One is the technical dimension, which includes the implementation of business code, interaction with database or other persistent storage, message queue, authentication and authorization, WebAPI exposure, etc. The second is the business dimension, there are too many modules and functions to do; The third is the time dimension, which requires rapid development, rapid response to changes in demand, and rapid Bug correction.

DDD deals with complexity in three main ways:

A. technical dimensions: through rational architectural layering, can let each layer focus on his own things, such as the domain layer only focus on business logic, storage and implementation layer focus on persistent data and query, application service layer focus on coordination field complete cases with warehousing implementation layer, interface layer focus on exposed to the front.

B. Business dimension: By dividing a large system into multiple bounded contexts, different teams and different people can focus only on the development of the current context. The domain layer, warehouse implementation layer, application service layer, and interface layer in the current boundary context are all separate from the other boundary context, allowing development to be focused and less influential when changing code and releasing products.

C. Time dimension: rapid verification and correction through agile iteration.

2. Effectively master DDD

A. Familiarize yourself with concepts: Familiarize yourself with bounded contexts, entities, value objects, domain services, aggregations, aggregation roots, repositories, application services, interfaces, etc. B. Be familiar with the architecture: Be familiar with the classic DDD architecture described in previous articles. C. Practice: The previous article analyzed the requirements from the three boundary contexts of product, distributor and order, established the domain model, and implemented the code through the classic DDD architecture, which requires you to use it flexibly in actual projects.Copy the code

3. Generation of interface documents

When we have done all the interfaces, we need to generate WebApi online interface documents for the front-end personnel to view and use. Net Core WebAPI uses Swagger to generate interface documentation.

1. Introduce the Nuget package Swashbuckle.AspNetCore in the WebApi project.

2. In WebApi project attribute generation, select XML Document File. The goal is to include annotations for every interface in the WebApi.

AddSwaggerGen(c => {c.swaggerDoc ("v1", new Info {Version = "v1", Title = "product limit context interface document ", Contact =new Contact {Name=" cao ",Email="[email protected]"}}); / / the annotation of the interface using Xml documents var basePath = ApplicationEnvironment. ApplicationBasePath; var xmlPath = Path.Combine(basePath, "Product.WebApi.xml"); c.IncludeXmlComments(xmlPath); });Copy the code

4. Add the following code to the Configure method:

App.useswagger (); app.useswagger (); App.useswaggerui (p => {p.waggerendpoint ("/swagger/v1/swagger. Json ", "Product interface "); });Copy the code

LaunchUrl launchSettings.json = swagger > LaunchSettings. json = swagger > LaunchSettings. json

"profiles": {
"IIS Express": {
  "commandName": "IISExpress",
  "launchBrowser": true,
  "launchUrl": "swagger",
  "environmentVariables": {
    "ASPNETCORE_ENVIRONMENT": "Development"
  }
},
"Product.WebApi": {
  "commandName": "Project",
  "launchBrowser": true,
  "launchUrl": "swagger",
  "environmentVariables": {
    "ASPNETCORE_ENVIRONMENT": "Development"
  },
  "applicationUrl": "http://localhost:5000"
}
Copy the code

}

6. When accessing, the final effect is as follows:

This is the end of this series of articles, this series of articles is mainly to explain the classic DDD, about CQRS DDD and micro services, you can continue to follow our series of articles, you can also join the QQ group or follow our wechat public number. In the subsequent content of CQRS and microservices, we will implement the following architecture

Microservice architecture:

CQRS architecture:

DDD combat advanced video please pay attention to wechat public number: MSSHCJ