Domain driven design 聚合中的域驱动设计和本地标识

Domain driven design 聚合中的域驱动设计和本地标识,domain-driven-design,aggregate,identity,Domain Driven Design,Aggregate,Identity,在域驱动的设计中,有一个引用内部实体的聚合根 聚合根是具有全局标识的实体(每个人都可以使用其id)。聚合根具有指向本地对象(实体)的链接 假设这里的实体是Hibernate@Entities(比方说) 假设我们有聚合根“User”,其中包含“Address”实体作为对象(实际上也是一个实体) 问题是: 如何使本地实体仅具有本地标识。我的意思是,没有任何障碍可以阻止任何人通过其ID使用本地实体(如地址)。(因此,这种身份根本不是本地的,而是全球的)。那么,如何使其成为本地的呢?所有实体,包括根,都

在域驱动的设计中,有一个引用内部实体的聚合根

聚合根是具有全局标识的实体(每个人都可以使用其id)。聚合根具有指向本地对象(实体)的链接

假设这里的实体是Hibernate@Entities(比方说)

假设我们有聚合根“User”,其中包含“Address”实体作为对象(实际上也是一个实体)

问题是:
如何使本地实体仅具有本地标识。我的意思是,没有任何障碍可以阻止任何人通过其ID使用本地实体(如地址)。(因此,这种身份根本不是本地的,而是全球的)。那么,如何使其成为本地的呢?

所有实体,包括根,都有一个标识。事实上,只有聚合根的标识应该“全局”使用,这是代码本身无法轻松实施的。特别是在关系数据库中,每个表记录都有一些键,而不管该记录存储的是聚合根、实体还是值对象。因此,由开发人员确定哪些数据库标识是域的一部分,哪些不是域的一部分。

聚合根中的实体应该只具有本地标识。出于所有目的,数据库表不需要主键。当骨料水合时,应根据其与AR的链接提取AR中的实体。但即使FK也不需要在本地实体中表示,因为基于本地实体与AR的包容,连接是明显的


由于大多数数据库系统都会抱怨表上没有PK,因此您可以添加一个PK,但您可以在实体设计中忽略它。因此实体中没有PK的属性。然后,人们可以通过DB访问该实体的唯一方法是,因为在您的代码中不应该有这样的方法。

我认为这不是公共字段或属性或某种访问限制机制的问题,我认为这是“本地身份”的问题表示聚合边界之外的对象不能以有意义或有用的方式使用该本地标识(例如,它们不能使用该标识检索该对象或将其持久化到数据库或任何其他操作)。这种身份对外部世界来说没有任何意义,它只在这个群体中是独一无二的。另一个例子是,什么可以保证聚合边界之外的对象不会包含对聚合边界内对象的引用(这违反了聚合的一个原则),除非这些对象是值对象(可能不是每次都是值对象),否则什么都没有。如果我想说几句话:不要在聚合中创建任何使用对象标识的公共API,这样您就可以让开发人员明白不要使用这些标识