Domain driven design 附件管理

我正在构建一个系统，在这个系统中，

会议

可以有零个或多个

附件

s。 为了避免每次加载

会议时加载整个附件二进制文件，我有一个
附件中心（大小、mimetype、引用、名称、哈希）

此引用是通过一个工厂创建的，该工厂猜测
mimetype
，计算
散列和
大小，并确保所有内容都保存在二进制内容之外：
AttachmentsFactory.create（名称，字节[]）：AttachmentRef

然后，当用户想要检索附件时，它必须取消引用。
附件
与引用大致相同，只是它具有二进制内容
附件（大小、mimetype、名称、内容）
（将通过引用和字节[]的组合来实现）

我的问题是关于这个附件的检索，我有两个主要的可能性，我想知道哪一个在“DDD”设计中看起来最好

1-哑参考，智能服务

AttachementService {
  dereference(ref):Attachment {
    // Get the binary, recompute and verify the hash and return an Attachment
  }
}

attachmentService.dereference(ref)

AttachmentService {
    read(ref):byte[] {
       // Just return the content for the ref
    }
}

AttachmentReference {
    dereference(attachmentService) {
        content = attachmentService.read(this)
        // recompute and verify the hash
        return new Attachment(this, content)
    }
}

ref.dereference(attachmentService)

2-智能参考，哑服务

AttachementService {
  dereference(ref):Attachment {
    // Get the binary, recompute and verify the hash and return an Attachment
  }
}

attachmentService.dereference(ref)

AttachmentService {
    read(ref):byte[] {
       // Just return the content for the ref
    }
}

AttachmentReference {
    dereference(attachmentService) {
        content = attachmentService.read(this)
        // recompute and verify the hash
        return new Attachment(this, content)
    }
}

ref.dereference(attachmentService)

这实际上是有界上下文之间交互的一个很好的例子

如果您的
会议
在一个BC中，并且您的内容在
内容
BC中，那么您很可能会在
会议
中将物理附加的内容（
字节[]
）表示为一个值对象，就像您对引用所做的那样

附加的内容可以表示为
ContentItem
或您的
content
BC中的某些内容，因为它将是聚合根

实际内容的检索通常发生在集成/应用层。在
会议上不需要这样做，因为我想这不会有多大作用。
好的，谢谢；这或多或少就是我的想法。但是要返回附件的内容，我必须验证他的哈希值没有改变。这是
附件中心的责任还是应用层的责任？实际上，计算散列并构建
AttachmentFactory
的是
AttachmentFactory
，但理想情况下，算法必须是相同的（代码），所以我应该把它放在哪里？我会将该处理放在应用程序/集成层。当您最初存储附件时，您需要计算哈希值，并且它与附件相关联。您甚至可能希望在附件中添加算法名称（或者在以后需要更改算法时这样做）。然后，当您检索内容时，例如，
ContentService
将注入哈希算法（或算法容器）。然后，它可以返回提取的结果，结果可以指示哈希是否匹配；否则，如果不匹配就会抛出异常并成为ops问题。非常感谢Eben