architecture - 域驱动设计共享实体

我刚刚开始以域驱动设计开始我的职业生涯。我的班级模型有问题。下面是简化的类图。

我有两个有界上下文：人口和问题。

Person是使用至少一个文档创建的。 Person可以报告附有多个Issue的新IssueAttachment。

我想将文件存储集中为一个File实体，并将其保存在单个数据库表中。集中化的原因是在持久性之前执行常见操作，例如数据压缩或获取md5哈希。另外，将所有文件存储在单个表中可以简化测试数据转储过程，因为我不得不忽略单个表以排除繁琐的Blob。

但是，在阅读了许多文章之后，我可以得出结论，不建议在各种上下文之间共享实体。

您能给我一些如何处理此类问题的设计建议吗？

如果您已经确定了两个有界上下文，那就太好了。请参考下图以从顶视图了解。

现在，如果我们查看每个有界上下文。在这种情况下，以洋葱架构为例，如图2所示。（您可以选择适合您需要的任何体系结构）。

是的，您没听错。确实，在两个不同的有界上下文中的模型是不同的。目前，您可能会看到具有相同属性的相同类。但是，由于它们处于不同的受限上下文中，因此它们对业务具有不同的含义。填补了基础设施与领域之间的空白后，可以尝试按照以下描述的方式进行思考。可能您会看到不同的含义。

但是，在您的情况下，可以在有界上下文的最外层处理与共享同一基础结构（例如文件系统）有关的问题，而不必担心或与您的域名业务混在一起。

从图2中可以看到，

使用位于外壳最外层的基础层与共享的基础结构（例如：文件系统）进行交互。现在，在域中（分别是填充或发布上下文）定义一个接口，该接口定义了各自的业务需求。您可以在应用程序层中实现该功能，从那里您可以与基础层（具有相同边界上下文）进行交互。反过来，您将能够与共享基础结构（文件系统）进行通信。

明天使用哪个基础架构和域名业务的基础架构都将保持不变，这并不重要。因此，您可以通过这种方式使事物保持隔离状态。在基础层中，更改很少，并且具有某种映射器或适配器，您将能够与共享基础结构（文件系统）进行神奇的交互。

让我知道您的想法。