Domain Primitive usage recommendation

1、 Preface

Recently, a code review was carried out on the code of many classmates in the team, and many problems were found.

One of the problems is that the general code cohesion is not enough, and the methods that originally need to be provided by objects are leaked to users.

If an object contains a status field, the user needs to judge whether it is successful according to the status.

public class SomeResult{

//A value of 0 indicates success

private String status;

//Label, where HOT means hot

private String tage;

private Map extInfo;

//Omit others

}

User:

if("0".equals(result.getStatus()) && "HOT".equals(result.getTag())){

//Execute a section of logic

}

Map extInfo = result.getExtraInfo();

extInfo.put("xxx", YYY);

In essence, the user only needs to let the result object "tell" whether it is successful and whether it is a popular material.

However, because the Result object has only properties and Getter and Setter methods, and no other properties, this part of logic needs to be perceived externally.

Essentially, we are used to writing anemia model code, that is, we only define attributes, assignment and value taking methods for objects, and put business logic into the service layer for processing.

It is more step-oriented programming, but it also violates the design pattern: Dimitr's Law.

The Law of Demeter is also called the Least Knowledge Principle. The less a class knows about other classes, the better. That is to say, an object should know as little as possible about other objects, only communicate with friends, not strangers. English abbreviation: LOD.

It also violates the class design principle of "encapsulation complexity".




2.2 Unnecessary magic value

Similar scenarios often require external perception of specific status codes and error codes, which need to be judged by various status codes, and then the corresponding logic can be executed.

Even if the interface provider gives an enumeration, the upstream also senses unnecessary logic.

If the interface provider does not provide enumerations, the user also needs to define constants or enumerations themselves.

However, most students like to be lazy, and usually use magic value to judge directly, resulting in poor readability.

The code reader has no idea what the various numbers or strings represent.




3、 Solution

3.1 Congestion model

An object contains not only data, but also its own operations.

To understand more comprehensive content, we need to systematically learn DDD related knowledge.

However, many projects of many teams are not developed with the idea and architecture of domain-driven design.

However, this does not prevent us from using some concepts in similar domain-driven design to design classes.

We can learn about Domain Primitive, and design the completely anaemic class as Domain Primitive or even as an entity and aggregate root in a DDD.

3.2 Domain Primitive

3.2 Part of it is reprinted from Alibaba Technical Experts Explaining DDD Series - Domain Primitive

3.2.1 Domain Primitive definition

Domain Primitive (DP) is a value object with precise definition, self-verification and behavior in a specific field.

DP is a value object in the traditional sense and has the feature of immutable

DP is a complete concept with precise definition

DP uses native language in business domain

DP can be the smallest component of the business domain and can also build complex combinations

Note: The concept and name of Domain Primitive comes from the book "Secure by Design" by Dan Bergh Johnsson&Daniel Deogun.

3.2.2 Three principles of using Domain Primitive

• Make implicit concepts explicit

• Make the implicit context explicit

• Encapsulate multi-object behavior

3.2.3 Difference between Domain Primitive and Value Object in DDD

In DDD, the concept of Value Object already exists:

In Evans's DDD Blue Book, Value Object is more of a non-Entity value object

In Vernon's IDDD Redbook, the author pays more attention to the value object's immutability, Equals method, Factory method, etc

Domain Primitive is an advanced version of Value Object. On the basis of the original VO, each DP is required to have a conceptual whole, not just a value object. The validity and behavior are added on the basis of the immutable VO. Of course, the same requirement has no side-effect free.

3.2.4 Difference between Domain Primitive and Data Transfer Object (DTO)

Insert picture description here

3.2.5 Use scenarios of Domain Primitive

Common use scenarios of DP include:

• Strings with format restrictions: such as Name, PhoneNumber, OrderNumber, ZipCode, Address, etc

• Limited Integers: such as OrderId (>0), Percentage (0-100%), Quantity (>=0), etc

• Enumerable ints: such as Status (Enum is generally not used because of the deserialization problem)

• Double or BigDecimal: The commonly used Double or BigDecimal have business meanings, such as Temperature, Money, Amount, ExchangeRate, Rating, etc

• Complex data structures: For example, Map, etc., try to wrap all operations of Map and only expose necessary behaviors.


is business-oriented programming.




2、 Existing problems




2.1 Violation of software design principles

This violates the design principle of "high cohesion and weak coupling" in the field of software engineering.

3.3 Simplified case

The first case can be optimized to encapsulate the complexity in the object for upstream use.

Of course, this example is very simple. I just want to help you understand this concept. The scenarios encountered in actual development may be much more complex, and there may be many methods to encapsulate.

In practice, you can:

Validity verification of parameters

Business status judgment

Some processing methods related to this type of attribute

The operation that needs to be performed after obtaining the internal properties of the object

...

All are encapsulated into this object to reduce coupling and encapsulation complexity.




4、 Summary

Most programmers, accustomed to writing anemia model code, are unwilling to learn the concept and practice of domain-driven design.

Many programmers subconsciously believe that team projects should not or need to write hyperemia model code without clearly using the idea and framework of domain-driven design.

The world is not black or white. Even if the team does not explicitly use domain-driven design, or even anemia models are flying around, we can also infiltrate design principles into coding.