知识卡片
值对象与实体的判定标准:生命周期归属与查询模式
内容
事件风暴构建领域模型阶段,不需要严格区分一个领域对象到底是实体还是值对象;但到了从领域模型映射到代码模型、完成微服务设计这一步,就必须根据具体业务场景把它们明确区分开。书中给出了一条具体、可操作的判定标准:如果这个领域对象的生命周期是在其他聚合内被管理的,而当前聚合里引用它的实体只被允许对它做整体替换(不能单独修改它内部某个属性),那么应该把它设计为值对象;反过来,如果这个领域对象自己拥有多条独立的数据记录,而且业务上需要基于它做频繁的查询和统计,那么应该把它设计为实体。书中还给出一个容易被忽略的类型:像”客户证件类型”这种以枚举值形式存在的属性,一般也应该设计为值对象。这条判定标准把[[值对象的核心特征无标识基于属性值不可变]]和[[实体的核心特征唯一标识符与延续性]]这两个偏概念性的定义,转化成了工程实践中真正可以拿来做决策的两个具体问题:”这份数据的生命周期归属在哪里、外部只能整体替换还是可以局部修改?”以及”业务上是否需要对它做独立的查询统计?”——回答清楚这两个问题,大部分实体/值对象的判定分歧就能解决。
参考来源
- 位置:第15章《如何保证领域模型与代码模型一致》"15.2.1 领域层的领域对象","3. 设计值对象"(源文件:_epub-src/OEBPS/Text/chapter4-4-2-1.xhtml)
- 结论依据:原文说明"如果这个领域对象在其他聚合内进行生命周期管理,并且引用它的实体对象只允许对它整体替换,我们就可以将它设计为值对象。如果这个领域对象有多条数据记录且需要基于它进行频繁的查询统计,则建议将它设计为实体……客户拥有客户证件类型,它以枚举值的形式存在。一般我们可以将枚举值类型的属性设计为值对象",直接支撑本卡片结论。
- 原始内容:如果这个领域对象在其他聚合内进行生命周期管理,并且引用它的实体对象只允许对它整体替换,我们就可以将它设计为值对象。如果这个领域对象有多条数据记录且需要基于它进行频繁的查询统计,则建议将它设计为实体。