学习DDD，在我们的应用程序中存在三个聚合根，不同类型的表单，所有这些都需要上传一些PDF。这些 pdf 上传附加了一些元数据，例如上传者和上传时间等，以便将它们存储在自己的表中。

我的问题是这个 PDF 是否应该建模为值对象、实体或聚合根。

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

Update

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类应该被建模为值对象（或）实体（或）聚合根。引用《领域驱动设计精炼》，Vaughn Vernon (ISBN-13: 978-0134434421) https://rads.stackoverflow.com/amzn/click/com/0134434420:

此外，值对象不是事物，但通常用于描述、量化或测量实体。

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