entity - DDD : Share entity with multiple aggregate roots

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

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

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

更新

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类建模为值对象(或实体)(或聚合根)。引用«Domain-Driven Design Distilled», Vaughn Vernon (ISBN-13: 978-0134434421):

最佳答案

我认为“附件”概念更适合“值(value)对象”概念，因为没有生命周期，并且字段自然是不可变的。
数据库条目具有主键的事实并不意味着它必须是域上下文中的实体。

关于entity - DDD : Share entity with multiple aggregate roots，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/47396674/