这是DDD实践中非常常见的困惑，我来拆解一下你的问题：

首先明确：DDD中的实体绝对不是纯数据模型，它是领域概念的具象化，必须同时包含数据（属性）和行为（业务规则）。

你提到的“纯数据模型”其实是典型的贫血模型，这种模式的问题在于：

• 业务逻辑会散落在服务层、控制器甚至工具类中，导致代码难以维护，逻辑重复。
• 无法保证数据的一致性：比如一个用户实体，年龄不能为负数，如果只是纯数据模型，你需要在每个修改年龄的地方都加校验，很容易遗漏。
• 领域概念被弱化：实体变成了单纯的容器，失去了表达领域语义的能力。

举个实际例子：假设你有一个Order实体，业务规则是“只有待支付的订单才能被标记为已支付”。如果把规则放在实体里：

public class Order {
    private OrderStatus status;

    public void markAsPaid() {
        if (status != OrderStatus.PENDING_PAYMENT) {
            throw new IllegalArgumentException("只有待支付的订单才能完成支付");
        }
        this.status = OrderStatus.PAID;
    }
}

这样无论哪里调用order.markAsPaid()，都能自动遵守规则，不会出现状态非法的情况。如果是纯数据模型，你就得在服务层写一堆if判断，逻辑散落在各处，风险极高。

你提到的“数据库→持久化模型→领域模型→DTO”三层映射确实会增加工作量，但这不是必须的强制方案，可以根据业务复杂度灵活调整：

1. 简单业务：合并领域实体与持久化模型 #

如果你的业务逻辑不复杂，数据库结构和领域模型高度对齐，可以让领域实体直接作为持久化模型（比如添加JPA的@Entity注解）。但要注意：

• 不要在实体中加入持久化相关的逻辑（比如自定义SQL查询），这些应该放在Repository接口中。
• 保持实体的领域行为纯粹，持久化注解只是“附加属性”，不影响领域逻辑的表达。

这样就省去了“持久化模型→领域模型”的映射，只剩下数据库→实体→DTO的两层，甚至在一些简单场景下，DTO可以直接复用实体的部分属性（但不建议长期这么做，避免领域逻辑泄露到外部）。

2. 复杂业务：用工具简化映射 #

如果确实需要分离领域模型和持久化模型（比如数据库设计和领域模型差异较大，或者需要优化性能），可以用映射工具来减少手动工作量：

• 比如Java中的MapStruct，它能通过注解自动生成类型安全的映射代码，不需要手动写一堆setter。
• 或者在.NET中用AutoMapper，同样能自动处理大部分字段的映射。

另外，DTO不需要完全映射所有领域属性，只需要暴露外部需要的字段，这样映射的工作量其实远没有你想象的大。你还可以在领域实体中添加方法来生成DTO，比如：

public OrderDto toDto() {
    return new OrderDto(this.id, this.status, this.totalAmount);
}

这样把转换逻辑内聚在实体中，代码更清晰。

3. 避免过度设计 #

很多时候，我们会陷入“为了分离而分离”的误区。DDD的核心是聚焦领域逻辑，而不是严格遵守某种分层规范。如果三层映射给你带来的维护成本超过了它的收益，那完全可以调整方案，比如：

• 直接在应用层用领域实体处理请求，但要注意不要把实体暴露给外部系统，而是在应用层做转换。
• 对于一些简单的查询场景，可以直接用DTO从数据库查询（比如用JPA的@Query返回DTO），不需要经过领域模型。

• 实体包含业务规则是DDD的核心原则之一，目的是保证领域一致性，避免贫血模型的问题。
• 三层映射不是必须的，根据业务复杂度选择合适的方案，用工具简化重复工作。
• 永远以领域逻辑的清晰性为第一优先级，不要为了分层而分层。

内容的提问来源于stack exchange，提问作者Behzad