Question

我正在建立一个Meeting可以有零个或多个Attachment的系统。为避免每次加载Meeting时加载整个附件二进制文件，我都有AttachmentRef(size, mimetype, reference, name, hash)。

此引用是通过猜测mimetype，计算hash和size的工厂创建的，并确保除二进制内容之外的所有内容都已保存：AttachmentsFactory.create(name, byte[]):AttachmentRef。

然后，当用户想要检索附件时，必须取消引用该引用。 Attachment或多或少与引用相同，只是它具有二进制内容Attachment(size, mimetype, name, content)（它可以使用引用和byte []的组合实现。）

我的问题是关于这个附件的检索，我有两个主要的可能性，我想知道哪一个在＆＃34; DDD＆＃34;设计？

1 - 哑巴参考，智能服务

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

attachmentService.dereference(ref)

2 - 智能参考，哑巴服务

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)

Answer 1

这实际上是 Bounded Contexts 之间相互作用的一个很好的例子。

如果您的Meeting位于BC省内且您的内容位于Content BC，那么您很可能将物理附加内容（byte[]）表示为值正如您在参考中所做的那样，Meeting中的对象。

附加内容可能在ContentItem BC中表示为Content或某些内容，并且它将是聚合根。

实际内容的检索通常会发生在集成/应用层上。我认为，不需要在公元前Meeting进行，因为它不会做太多。

附件管理

1 个答案: