04-实体与标识-DDD领域驱动设计

title: "04 实体（Entity）与标识"

学习目标

理解实体（Entity）的定义：以标识（Identity）区分，而不是以属性值区分
能在"实体 vs 值对象（Value Object）"之间做出建模选择，并说清理由
能把"标识、生命周期、相等性（Equality）"这三件事落实到代码与讨论中

核心概念

实体是什么

实体表示领域中的"对象"，它的关键特征是：

有稳定的标识（Identity）：在其生命周期内保持不变
会随时间变化（Mutable）：状态会发生演化（例如订单从 CREATED → PAID）
相等性用标识判断：即使属性值变了，它仍然是"同一个实体"

标识（Identity）是什么

标识是用来回答一句话的："你是谁？"

在 DDD 中，标识通常不等同于数据库自增主键；它更像领域中的"业务编号/自然键"，例如订单号、客户号、合同号等。

在本书示例（订单域）中，Order 的标识是 OrderNumber（值对象），不是 long id：

OrderNumber：包含格式校验（ORDER-[A-Z0-9]{16}），并被 Order 聚合根持有
CustomerId：同样是值对象，用来表达客户的身份

课堂讲授：为什么实体不是"数据库表的一行"

很多初学者会把实体理解为"ORM 的 @Entity"。这会把注意力放到"表结构/字段映射"，而忽略实体的真正价值：封装业务规则与状态演化。

一个好用的教学判断：

如果你在讨论中频繁使用"同一个 X（哪怕属性不同）"，那它往往是实体
如果你在讨论中频繁使用"只要值相同就一样"，那它往往是值对象

伪代码示例：实体围绕"标识 + 状态机 + 行为"

下面的伪代码形状展示了一个典型订单实体/聚合根的结构（包含 addItem/pay 等行为，以及 OrderStatus 状态机）。

text 复制代码

class Order {                       // Entity / Aggregate Root
  orderNumber: OrderNumber          // Identity (VO)
  customerId: CustomerId            // VO
  status: OrderStatus               // State machine (VO-like)
  items: List<OrderItem>            // VO collection

  addItem(item):
    require status.canPay()
    require items.size < MAX_ORDER_LINES
    items.add(item)

  pay():
    require OrderPaymentSpecification().isSatisfiedBy(this)
    status = status.transitionToPaid()
    domainEvents.add(OrderPaidEvent(...))
}

实体的相等性（Equality）约定

课堂统一口径建议：

实体相等性只看标识 ：OrderNumber 一样就是同一订单
值对象相等性看所有属性值 ：OrderNumber("ORDER-...") 值相同就是同一个值

这会直接影响：

你怎么写 equals/hashCode
你如何去重、如何做集合操作（Set/Map）
你如何在日志/事件/接口中传递身份信息

常见误区

误区 1：把数据库主键当领域标识：导致"业务上订单号变化/迁移/合并"时建模困难；讨论也会被技术细节带跑
误区 2：实体没有行为，只有 getter/setter：业务规则散落在 Application Service / Controller，模型贫血
误区 3：实体相等性用所有字段比较：任何字段变化都会让"同一个实体"在集合里变成"另一个对象"

课堂练习

以"订单"为例，请完成以下建模判断题（写出理由）：

Order 是实体还是值对象？它的标识是什么？
OrderNumber 是实体还是值对象？为什么不把它做成 String？
如果"客户可以修改收货地址"，Address 更像实体还是值对象？（提示：看是否需要独立标识与生命周期）

自测题

你如何用一句话区分实体与值对象？
为什么说"实体不是数据库表的一行"？请举出一个业务规则的例子。
在你的项目里，最容易被误建成实体的值对象是什么？