DDD中属性唯一性：何时视为领域不变量而非技术关注点？

核心判断标准 #

判断唯一性属于领域不变量还是技术关注点，核心看这个唯一性是否是业务规则的一部分，或者是业务逻辑正确运行的必要前提——和谁生成它无关：

• 如果违反唯一性会直接破坏业务逻辑（比如用户邮箱重复导致登录混淆、预订ID重复导致修改错误订单），那它就是领域不变量，必须在领域层明确约束。
• 如果唯一性只是为了技术实现便利（比如数据库索引、缓存键区分），不影响业务规则的执行，那就是纯技术关注点，交给基础设施处理即可。

针对你提到的场景分析 #

1. 用户登录邮箱（业务属性） #

毫无疑问是领域不变量。业务上明确要求“一个邮箱只能对应一个用户”，这是用户识别、认证的核心规则，违反会直接导致业务流程失效。实现上可以在User聚合根的创建逻辑中，通过领域服务查询领域仓库校验邮箱唯一性，再完成创建。

2. 预订ID（自动生成的技术标识符） #

属于领域不变量。虽然它由基础设施生成，但业务上要求每个预订是唯一的实体，所有后续业务操作（修改、取消、关联支付）都依赖这个ID来定位具体预订。如果出现重复ID，会导致业务数据混乱、逻辑错误。

不过实现上可以做分层处理：

• 领域层只定义“每个预订必须拥有唯一ID”的规则，确保创建Reservation实体时必须传入有效的唯一ID，不允许无ID的实体存在。
• 具体的ID生成和唯一性保障可以交给基础设施（比如数据库自增主键、UUID生成器），但领域层要通过抽象接口（比如ReservationIdGenerator）依赖，避免直接耦合数据库逻辑。

最佳实践 #

1. 领域不变量的唯一性：领域定义规则，基础设施辅助保障
   • 业务属性的唯一性：在聚合根或领域服务中实现校验逻辑，确保创建/修改时符合业务规则。比如创建用户前，领域服务先查询仓库是否存在相同邮箱的用户。
   • 技术标识符的唯一性：领域层只约定“实体必须有唯一标识”，具体生成逻辑由基础设施实现，但领域层要确保实体创建时必须获得合法的唯一ID，拒绝无效状态的实体。
2. 技术关注点的唯一性：完全交由基础设施处理
   • 比如日志追踪ID、缓存键这类业务不关心的标识，只需要技术层确保其在技术场景内唯一即可，领域层无需介入。
3. 避免过度耦合基础设施
   • 即使是技术标识符，领域层也不应该直接依赖数据库自增、UUID等具体实现，而是通过抽象的生成器接口，让基础设施提供实现，保持领域层的独立性。

DDD核心思路参考 #

领域不变量是必须始终成立的业务规则，是领域模型的核心约束。埃里克·埃文斯在《领域驱动设计》中提到：聚合要维护自身的不变量，跨聚合的不变量由领域服务维护。唯一性约束如果是单个聚合的属性，可在聚合内或领域服务中校验；如果是全局范围的（比如全局唯一的预订ID），则需要领域服务结合基础设施的原子性保障（比如数据库主键约束）来实现。

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