我刚刚从领域驱动设计开始我的职业生涯。我的班级模型有问题。下面是一个简化的类图。
我有两个有界上下文：Population 和 Issues。
Person 至少包含一个文档。 Person 可以报告一个新的Issue 附加多个IssueAttachment。
我想将文件存储集中为单个 File 实体，我将保留在单个数据库表中。中心化的原因是在持久化之前执行常见的操作，例如数据压缩或获取 md5 哈希。此外，将所有文件存储在单个表中简化了测试数据转储过程，因为我必须忽略单个表以排除重 blob。
但是，在阅读了很多文章之后，我可以得出结论，不建议在各种上下文之间共享实体。
您能给我一些关于如何处理此类问题的设计建议吗？
【问题讨论】：
标签： architecture domain-driven-design entity-relationship bounded-contexts
如果您已经确定了两个有界上下文，那就太好了。请参考下图从俯视图了解。
现在，如果我们查看这些有界上下文中的每一个。在这种情况下，以洋葱架构为例，如图 2 所示。 （您可以选择任何适合您需要的架构）。
是的，你没听错。确实，两个不同的有界上下文中的模型是不同的。目前，您可能会看到具有相同属性的相同类。 但是由于它们处于不同的有界上下文中，因此它们对业务具有不同的含义。一旦您填补了基础设施与域之间的空白，可能会尝试按照以下描述的方式进行思考。可能你会看到不同的含义。
但是，在您的情况下，您对共享相同基础设施（例如：文件系统）的担忧可以在有界上下文的最外层处理，而无需担心或与您的域业务混为一谈。
如图 2 所示，使用位于外壳最外层的基础设施层与共享基础设施（例如：文件系统）进行交互。现在在域中（分别是总体或问题上下文）定义一个定义相应业务需求的接口。您可以在应用程序层中实现它，从那里您可以与您的基础层（具有相同的有界上下文）进行交互。反过来，您将能够与共享基础架构（文件系统）进行通信。
明天您将使用哪个基础设施以及您的领域业务的基础设施发生什么变化都不会影响它。因此，通过这种方式，您可以保持隔离。并且在更改非常少并且拥有某种映射器或适配器的基础层中，您将能够与共享基础架构（文件系统）进行神奇的交互。
让我知道你的想法。
【讨论】：
Person 创建一个新问题，作为请求的 DTO，我将获取与问题本身和文件数组相关的数据。我将把它传递给 ReportNewIssueUseCase，在那里我将实现域模型之间的交互并通过存储库持久化数据。基于该步骤，我怀疑此用例将如何保存文件并将它们与问题相关联？我相信我肯定应该为数据持久性创建 FileRepository。从定义上看，Repositories 持久化和检索域实体，因为 File 不是域实体，那么如何与 Repository 交互以将 File 存储到数据库表中？