How can we organize domain logic through Domain Models?

Select the development method and select physicalProgramBut how to organize these business logic is also a big problem. First, we need to find out what logic belongs to the domain logic, which is a big challenge. In many cases, it takes a long time to determine whether a logic should belong to the domain logic, infrastructure, or others. This puts forward high requirements for developers who use domain-driven design and DDD hierarchy. However, once you are familiar with this method, you can easily solve the complicated logic.

What should we put in the domain model? I have summarized the following points, but this is not the best. I am also learning.

First, anything related to the UI must not be placed on the logic layer of the domain. That is, the Assembly containing the domain model logic will never rely on the UI library.

Second, when it comes to using a library in a certain field, we will consider it. For example, to create a GIS project, there is a layer concept, and there may be some configuration information classes for layers. I think these layers need to be referenced in the domain model. Because it is impossible for you to package interfaces of these layers into layers, and avoid dependencies on these third-party libraries in the domain model. In that case, the cost is too high. This may happen. The core DLL of the third-party library you use depends on some UI libraries. I do not know how to deal with this situation. I can only say that the third-party library is not very good. The final decision is to rely on this database, but this is in conflict with the first article. No way.

Third, the logic that users can understand should be put into the domain model. Put the implementation of user non-relational into the infrastructure layer. For example, the price of a user relationship product cannot exceed 10 thousand. The user knows that the school distribution data is a vector data. The user knows the concept of a map and the map contains several layers. However, users do not care about where your data exists, how to display the map on the desktop, and how to implement the specific technology of sending emails.

Ideally, if you use donet for development, the domain model assembly should only rely on several of the most basic DLL in donet.

Although there are some rules that can be judged, there are some special situations that need to be handled whenever specific situations are encountered, and there are often many other special cases. This depends on the experience of the designers and developers. Some logics are vague, and it seems appropriate to put them on that layer.

The domain model includes entity objects and value objects. an object is a unique object in the system. A value object is an object that can be shared and reused. the information in the domain model includes both persistent information and auxiliary information. in short, Domain Models should basically define various terms in customer requirements.

In this way, the customer's needs can be fully captured and the changes in user needs can be well handled,

When defining a domain model, you can use inheritance, polymorphism, and other features. All definitions match the actual situation. As for how to map these object to the database, it is the responsibility of the data persistence layer. Sometimes, some infrastructure layers may slightly modify the domain model to facilitate the use of the data persistence layer, however, the domain layer must not be completely changed for these reasons '.

This layer is the core layer of the entire system. This module is the first module to be determined and started during initial development of requirements and systems.