领域驱动设计共享实体

Question

我刚刚开始我的领域驱动设计职业之旅。我的课程模型有问题。下面是一个简化的类图。

我有两个有界上下文：Population和Issues。

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

我想将文件存储集中为单个File实体，并将其保留在单个数据库表中。中心化的原因是在持久化之前执行常见操作，例如数据压缩或获取 md5 哈希。此外，将所有文件存储在单个表中还简化了测试数据转储过程，因为我必须忽略单个表来排除大量 blob。

然而，在阅读了很多文章之后，我可以得出结论，不建议在不同上下文之间共享实体。

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

Answer 1

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

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

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

然而，就您而言，您对共享相同基础设施（例如：文件系统）的担忧可以在有界上下文的最外层处理，而不必担心或与您的域业务混合。

从图 2 中可以看出，使用位于 shell 最外层的基础层与共享基础设施（例如：文件系统）进行交互。现在，在域（分别是人口或问题上下文）中定义一个接口，该接口定义了各自的业务需求。您可以在应用程序层中实现它，您可以在应用程序层中与您的基础层（相同的有界上下文）进行交互。反过来，您将能够与共享基础设施（文件系统）进行通信。

明天您将使用哪种基础设施，以及基础设施发生什么变化，您的域业务都保持不变，这并不重要。因此，通过这种方式，您可以保持事物隔离。在基础层中，只需很少的更改并拥有某种映射器或适配器，您将能够与共享基础设施（文件系统）进行神奇的交互。

让我知道你的想法。