我刚刚开始我的领域驱动设计职业之旅。我的类(class)模型有问题。下面是一个简化的类图。
我有两个有界上下文:人口和问题。
Person 是使用至少一个文档创建的。 Person 可以报告附加多个 IssueAttachment 的新 Issue。
我希望将文件存储集中为单个 File 实体，并将其保留在单个数据库表中。中心化的原因是在持久化之前执行常见操作，例如数据压缩或获取 md5 哈希。此外，将所有文件存储在单个表中还简化了测试数据转储过程，因为我必须忽略单个表来排除大量 blob。
但是，在阅读了很多文章之后，我可以得出结论，不建议在不同上下文之间共享实体。
您能给我一些关于如何处理此类问题的设计建议吗？
最佳答案
如果您已经确定了两个有界上下文，那就太好了。请引用下图从俯 View 来理解。
现在，如果我们查看每个有界上下文。在本例中，以洋葱架构为例，如图 2 所示。 (您可以选择适合您需要的任何架构)。
是的，你没有听错。确实，两个不同的有界上下文中的模型是不同的。目前您可能会看到具有相同属性的同一类。 但由于它们处于不同的有界上下文中，因此它们对业务具有不同的含义。一旦您填补了基础设施与域之间的空白，就可以尝试按照以下描述的方式进行思考。也许你会看到不同的含义。
但是，就您而言，您对共享相同基础设施(例如:文件系统)的担忧可以在有界上下文的最外层处理，而不必担心或与您的域业务混合。
从图 2 中可以看出，使用位于 shell 最外层的基础层与共享基础设施(例如:文件系统)进行交互。现在，在域(分别是人口或问题上下文)中定义一个接口(interface)，该接口(interface)定义了各自的业务需求。您可以在应用程序层中实现它，您可以在应用程序层中与您的基础层(相同的有界上下文)进行交互。反过来，您将能够与共享基础设施(文件系统)进行通信。
明天您将使用哪种基础设施，以及基础设施发生什么变化，您的域名业务都不会受到影响。因此，通过这种方式，您可以保持事物隔离。在基础层中，只需很少的更改并拥有某种映射器或适配器，您将能够与共享基础设施(文件系统)进行神奇的交互。
让我知道你的想法。
关于architecture - 领域驱动设计共享实体，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/62758995/