How Rich Models Supercharge DDD Entity Design and Boost Maintainability

Background

Rich model is a DDD entity design approach that focuses on business implementation, improving development efficiency and maintainability.

Overall Call Relationship in DDD Project

In the call relationship diagram, Entity is used from entering the domain service (Domain) until the final return.

Entity Design

Rich Model Overview

Rich model is a method where entities contain specific behavior methods and aggregation relationships.

Key terms: domain service → aggregate → aggregate root → entity → anemic model → rich model.

Aggregate and Aggregate Root

An aggregate is a relationship, and the aggregate root is the foundation of that relationship; without it, the aggregate cannot exist.

Example: three entities—User, UserGroup, UserGroupRelation—form an aggregate, with User as the aggregate root.

Entity

Defined in the domain layer, entities are core elements; they may map to database tables but can also represent one-to-many or in‑memory objects.

Anemic Model

Entities without behavior methods or aggregation relationships, essentially value objects used for data transfer; not recommended.

Rich Model

Entities contain behavior methods (e.g., create, save, delete) and aggregation references, allowing operations through the entity.

In practice, using rich models hides glue code, improves readability, and keeps focus on business logic.

Problems with Rich Model

Too much behavior can make entities bloated and hard to read or maintain; solutions depend on the amount of behavior code.

Solutions

Scenario 1: Behavior does not bloat the entity

public CooperateServicePackageConfig save() {
    // Directly call infrastructure layer to save
    cooperateServicePackageConfigRepository.save(this);
    return this;
}

Scenario 2: Behavior causes entity bloat

Move behavior to external classes.

1) Utility class

public CooperateServicePackageConfig save() {
    // Delegate processing to utility class
    ServicePackageSaveUtils.save(this);
    return this;
}

2) New entity for specific behavior

Practical Experience

1. Spring bean injection: static injection within entities.

private LabelInfoRepository labelInfoRepository = ApplicationContextUtils.getBean(LabelInfoRepository.class);

2. Entity serialization: exclude unnecessary properties for Redis caching.

// Exclude serialization attribute
@Getter(AccessLevel.NONE)
private LabelInfoRepository labelInfoRepository = ApplicationContextUtils.getBean(LabelInfoRepository.class);

// Exclude serialization with JSONField
@JSONField(serialize = false)
private ServicePackageConfig servicePackageConfig;

// Exclude getter method from serialization
@Transient
@JSONField(serialize = false)
public static CooperateServicePackageRepositoryQuery getAllCodeQuery(Long contractId) {
    CooperateServicePackageRepositoryQuery repositoryQuery = new CooperateServicePackageRepositoryQuery();
    repositoryQuery.setContractIds(Lists.newArrayList(contractId));
    repositoryQuery.setCode(RightsPlatformConstants.CODE_ALL);
    return repositoryQuery;
}

3. Using setter to establish aggregate binding.

public void setServiceSkuInfos(List<ServiceSkuInfo> serviceSkuInfos) {
    if (CollectionUtils.isEmpty(serviceSkuInfos)) {
        return;
    }
    this.serviceSkuInfos = serviceSkuInfos;
    List<String> allSkuNoSet = serviceSkuInfos.stream()
        .map(one -> one.getSkuNo())
        .collect(Collectors.toList());
    String skuJoinStr = Joiner.on(GlobalConstant.SPLIT_CHAR).join(allSkuNoSet);
    this.setSkuNoSet(skuJoinStr);
}