Shulou(Shulou.com)05/31 Report--

This article mainly introduces the relevant knowledge of designing DDD-oriented micro-service knowledge points, the content is detailed and easy to understand, the operation is simple and fast, and has a certain reference value. I believe you will gain something after reading this DDD-oriented micro-service knowledge point. Let's take a look at it.

Domian-driven Design

Domain-driven-Design (DDD) advocates modeling based on (real-world business related to use cases).

1. From the perspective of DDD, DDD regards real problems as domains; DDD describes independent problems as bounded contexts (a bounded context corresponds to a microservice) and emphasizes that these issues are discussed in a common language. 2. Concepts proposed by DDD

Many technical concepts and patterns, such as hyperemia models (corresponding to anemia models we often write), value objects, aggregation, and aggregation root rules.

3. The present situation of implementing DDD

Sometimes DDD technical rules and patterns are seen as obstacles / verbosity, and the learning curve is steep for the implementation of the DDD approach.

Don't implement it for implementation's sake. The most important thing is to write domain code that is consistent with business issues in a common language.

In addition, you should use the DDD approach only if you want to implement micro-services with complex business rules, and simple responsibilities such as CRUD services can be managed in a simpler way.

DDD mode can help to demarcate the boundaries of microservices.

In the context of the boundaries that have been identified, you can model the domain: entity models, value objects, and aggregations, DDD related to boundaries, and micro services related to boundaries.

Try to keep small micro-services

To demarcate the boundary context, balance two goals:

Creating microservices as small as possible (which should not be the main driving force) to avoid overly dense communication between microservices

These two goals may contradict each other, and the two are balanced by evolution:

Decompose the system as much as possible until you feel a rapid increase in service traffic at the next decomposition.

The layers DDD in DDD microservices define multiple layers to manage the complexity of the code, and these layers are logical components (like interlocking gears). Different layers (such as domain model layer and presentation layer, etc.) may have different types, and the types between layers need to be transformed.

For example, entities loaded from a database sometimes need to be modified (intercept some information, add information) to adapt to the client UI.

A domain entity in the domain model layer should not propagate to other areas to which it does not belong (such as the presentation layer). It is important to have a domain model controlled by the aggregation root to ensure that all invariants and rules associated with the entity group (aggregation) are executed through a single entry point or (aggregation root).

The order DDD micro-service has three layers:

Application layer Ordering.API domain layer Ordering.Domain infrastructure layer Ordering.Infrastructure

The class library formed by the three layers has a clear and clear dependency.

1. The domain model layer

Responsible for expressing business concepts, business scenarios and business rules. This layer passes the technical details to the infrastructure layer, which controls and reflects the business scenario and is the core of the business software.

The domain model layer is the place to express the business and is programmatically embodied as a class library of domain entities that capture data and behavior (with logical methods).

Follow the principles of persistence and infrastructure non-awareness

The domain model layer must completely ignore the details of data persistence, and these persistence tasks should be performed by the infrastructure layer, so this layer should not be directly dependent on the infrastructure, which means that an important rule is that the domain model entity class should be POCO.

Domain entities should not directly rely on any data access infrastructure (EF, NHibernate), and ideally your domain entities should not inherit or implement any type defined in any infrastructure. Most modern ORM frameworks, such as Entity Framework Core, support this approach, so your domain model is not coupled to the infrastructure.

It is important to follow the persistence non-perception principle in the domain model, but the persistence problem should not be ignored.

It is still important to understand the physical data model and how it maps to your entity object model, otherwise your design will be a castle in the air. Moreover, most of the time you migrate designs that should have been relational databases directly to NoSQL or document-oriented databases, and the domain model layer is probably not applicable (based on storage and ORM technology, your entity model still has to comply with some constraints).

2. Application Layer

Define the work to be performed by the software and guide (congested domain objects) to solve the problem.

This layer is responsible for the business and sometimes interacts with the application layer of other systems.

This layer remains thin: it does not contain business rules or knowledge, but only coordinates tasks and delegates work to the next level of domain object collaboration

It does not reflect the status of the business situation, but it can have a status that reflects the progress of the task of the user or program.

In .NET, the application layer of micro services is generally represented by WebAPI,webapi interaction, remote network connection, and external request forwarding for UI/Client app. It is emphasized again that webapi should not contain business rules or domain knowledge (especially domain rules for transactions or updates), which should be owned by the domain model class library.

The application layer only coordinates tasks and cannot save or define any domain state (domain model). It delegates the execution of business rules to the domain model class itself (aggregation root and domain entities), which will eventually update the data in these domain entities.

Overall, the application layer is the place to implement front-end use cases.

3. The infrastructure layer

Infrastructure layer: a process that defines how data originally stored in a domain entity is persisted to a database or other storage structure.

An example is to implement a repository pattern class using Entity Framework Core code: this repository pattern class uses DBContext to persist data in a relational database.

According to the aforementioned principles of persistence and infrastructure non-awareness, the infrastructure layer must not "pollute" the domain model layer.

This is the end of this article on "what are the knowledge points of designing DDD-oriented microservices?" Thank you for reading! I believe you all have a certain understanding of "what are the knowledge points of designing micro-services for DDD". If you want to learn more, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.