对象引用与DDD聚合中Id的引用

Question

在Pluralsight课程领域驱动设计基础,有一个例子说明聚合物的设计是如何形成的.该示例涉及诊所中的患者预约.该约会与例如医生或检查室有关系.并且在该示例之前进行分析,得出结论:约会不应该是Doctor和ExamRoom的聚合根.设计演变的一个步骤是从具有对象引用的Appointment到Doctor和ExamRoom对象,到保存这些其他实体的原始id,DoctorId和ExamRoomId.他们通过以下方式激励这一变化:"通过简单地包含相关概念的ID而不是对象引用,我们能够确保在我们保留约会时创建和更改约会对我们的系统影响最小"

我的第一个问题:这是一种常见的设计模式吗？如果我理解正确,它会推广到如下:如果对象A与对象B相关,但在A上操作永远不需要对B进行更改,则通过其id而不是B本身引用它.这是你会推荐的吗？

我的第二个问题:这与DDD有什么关系吗？我的意思是,约会不应该是医生的总根,并不意味着它不能容纳对象,或者我错过了什么？

Answer 1

1. 我认为这是一种常见的设计模式,至少在DDD领域是如此.埃文斯在DDD中说:

根是AGGREGATE的唯一成员,允许外部对象持有引用

如果你使用像Hibernate这样的ORM,你可能不得不处理延迟加载以处理具有对象引用的深层链接对象结构.有些人认为延迟加载反模式.

看看这个QA,以更好地掌握聚合的概念.就个人而言,我确信明确定义的聚合边界可以改善您的架构.

2. 如果您实施聚合边界,您的约会类型很可能没有直接对象引用给医生.

更新: Vaughn Vernon谈论规则,阐明目前DDD领导人对聚合风格的一致看法(见第二部分):

[DDD]声明一个聚合可能包含对其他聚合的根的引用.但是,我们必须记住,这并不会将引用的聚合放在引用它的一致性边界内.该引用不会导致仅形成一个整体聚合.

他继续:

如果要在单个事务中修改多个实例,则可能表明您的一致性边界是错误的.如果是这样,那可能是错过的建模机会; 你的普遍存在的语言的概念尚未被发现,尽管它正在挥手并向你大喊大叫(见第一部分).

根据我的理解,约会不应该对像Doctor这样的其他聚合根进行直接对象引用.