Domain-driven design: more practice

The key issue of DDD is how to identify missing domain concepts. Eric's book provides some methods, suchListening to expressions, checking for inconsistencies, studying contradictions, etc. We need more practices to capture missing concepts.

New Practice: Check for changing the programming framework pairCodeImpact.

This practice is based on the following idea: the domain model should not change if the business logic does not change. therefore, if changing the programming framework causes a large number of business code changes, it means that some concepts are not encapsulated in the domain layer.

Here we do not advocate applicationProgramSupports dynamic switching programming frameworks, such as switching from one ORM tool to another, or switching from one MVC Framework to another. the emphasis here is that the domain model and concept should be expressed independently of the programming framework, although the final model needs to be called by the framework through some association or adaptation.

For example. before providing different services to customers, the company must sign a series of agreements with customers according to laws. this can be a sub domain of legal compliance. if the customer does not sign the agreement, the system rejects further services. if the system is a website, then, check the customer's agreement signing to determine whether the logic of continuing to provide services or rejecting can be put in the filter (almost all web programming frameworks provide pipeline-and filter-based architectures ). however, when we change the Web framework, we need to move this logic to the filter under the new framework. therefore, it is better to move this part of logic into a domain model, which can be modeled into rules to express every legal constraint to be observed, finally, you can connect them with pipelines and filters at the domain layer.

We don't have to really change the programming framework, just look at it. in the past, similar practices were supposed to provide different UIS for the system, such as a web UI and a command line UI, so that the business logic should not be coupled with the UI code. the practice is similar from different angles.

 

New Practice: focus on basic operations.

Frequent operation of basic types, especially in different cases, usually means the lack of domain concepts. for example, string type. if you find that you often need to take a certain segment of a string or locate a specific stator string, it is likely that the domain concept is encoded on the string as the implementation. in fact, except for the input/output or context boundary data exchange, there should be no string operations.

Another example is related to our interview questions and the round-robin during the calculation of the amount. if rounding is explicitly required by certain accounting rules, it should be explicitly modeled rather than implicitly expressed using some round () functions during computation.

 

working on more practice...