DDD:具有多个聚合根的共享实体 [英] DDD: Share entity with multiple aggregate roots

问题描述

学习DDD，在我们的应用程序中有三个聚合根，不同类型的表单，所有这些都需要一些PDF才能上载.这些pdf上载具有一些元数据，例如谁上载以及何时上载等等，因此它们存储在自己的表中.

Learning DDD, in our application there are three aggregate roots, different types of forms, all of which needs some PDF to be uploaded. These pdf uploads have some metadata, like who uploaded and when uploaded etc, attached to it so they are stored in their own table.

我的问题是，该PDF应该建模为值对象还是实体或聚合根.

My question is whether this PDF should be modeled as a value object or an entity or an aggregate root.

对我来说，它看起来像一个名为附件"的实体，但是此实体应该由所有聚合根共享，只有类型而不是实例共享.是否可以在多个根中使用相同的实体类型，如果是这样，那么模型的哪一部分应该负责创建该实体.

For me it looks like an entity named as "Attachment" but then this entity should be shared, only the type not the instances, by all the aggregate root. Is it an allowed practice to use same entity type in multiple roots, if so then which part of the model should take the responsibility for creating this entity.

class Attachment{
   Java.io.File pdf;
   Date attachedOn;
   .....
   //no operation for this class
}

@AggregateRoot
class DocumentA {
   Set<Attachment> attachments;
   Set<DocumentB> supportingDocumentsB;
   Set<DocumentA> supportingDocumentsA;
   .... //other properties unique to DocumentA

   attach(Attachment a);
   detach(Attachment a);
   addSupportingDocumentA(DocumentA doc);
   removeSupportingDocumentA(DocumentA doc);
   addSupportingDocumentB(DocumentB doc);
   removeSupportingDocumentB(DocumentB doc);
   .... //other operations unique to DocumentA
}

@AggregateRoot
class DocumentB {
   Set<Attachment> attachments;
   Set<DocumentB> supportingDocumentsB;
   Set<DocumentA> supportingDocumentsA;
   .... //other properties unique to DocumentB

   attach(Attachment a);
   detach(Attachment a);
   addSupportingDocumentA(DocumentA doc);
   removeSupportingDocumentA(DocumentA doc);
   addSupportingDocumentB(DocumentB doc);
   removeSupportingDocumentB(DocumentB doc);
   .... //other operations unique to DocumentB
}

@AggregateRoot
class SomeAggregateRoot{
   Set<Attachment> attachments;
   //some properties

   attach(Attachment a);
   detach(Attachment a);
   //some operations
}

现在的问题是，应该如何将Attachment类建模为值对象(或)实体(或)聚合根.引用«领域驱动的设计精粹»，沃恩·弗农(ISBN- 13:978-0134434421):

Now the question is how the Attachment class should be modeled, as a value object (or) an entity (or) an aggregate root. Quoting «Domain-Driven Design Distilled», Vaughn Vernon (ISBN-13: 978-0134434421):

此外，价值对象不是事物，而是经常用于描述，量化或度量实体.

Furthermore, a Value Object is not a thing but is often used to describe, quantify, or measure an entity.

推荐答案

我认为Attachment概念更适合Value Object概念，因为它没有生命周期，并且字段自然是不可变的. 数据库条目具有主键的事实并不意味着它必须是域上下文中的实体.

I think the Attachment concept fits better in the Value Object concept, since there is no life cycle and the fields are naturally immutable. The fact that the data base entry has an primary key doesn't imply it has to be an entity in the domain context.

这篇关于DDD:具有多个聚合根的共享实体的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！