DDD。共享内核？还是纯粹的事件驱动的微服务？

Question

我将我的系统分解为（至少）两个有限的背景：学习设计和调查计划。

有一个名为＆＃34; subject＆＃34; （研究设计背景下的潜在受访者）。我们还维护该领域的受试者和人群之间的关联。

现在，在调查计划中，我们还需要（一些）有关该主题的信息（例如：用于计划访问，或者甚至预期选择问卷，以防受试者所属的人口事先知道）

所以，我需要那个＆＃34;主题＆＃34;在两种情况下。

我应该采取什么方法？有一个共享内核，正如Eric Evans DDD一书中所解释的那样？我不介意（至少现在）让两个上下文共享同一个数据库。

或者......我应该去纯粹的微服务吗？含义：这两个人不能共享数据库......，在这种情况下，我可能必须通过事件传递去镜像/复制路径：https://www.infoq.com/news/2014/11/sharing-data-bounded-contexts

对于上述情况，对于哪一个更好的想法？

谢谢！

Answer 1

微服务的上下文是分布式系统。在任何其他情况下，它可能是矫枉过正。共享内核最终将分裂。通常就是这种情况。你可以从它开始。没有错。但是，它不会留在那里。

Answer 2

我建议您选择一个事件驱动的解决方案，但不一定要使用微服务。您可以构建一个事件驱动的整体，以便花费更少的时间来同步这两个模型。当应用程序变得太大时，您将整体块拆分为微服务。您可以使用CQRS将事件更多地分割为写入和读取。如果您使用事件采购，事情会变得更加有趣。

根据我的经验，使用共享内核，模型成为上帝对象，一种适合所有类型的对象。

Answer 3

在我看来，你有三个实体：

• 研究
• 调查
• 人

可以非常直观地看到每个都是它自己的聚合根。那么我们谈论的是根间关系。根据我的经验，这些实际上是有意义的实体，迄今为止最清洁和最具前途的证据是将这些关系视为独立的聚合根源。

研究与人之间的关系可能被称为TestSubject，人与调查之间的关系可以称为受访者或类似的东西。在另一个上下文中，该人可以是公司的雇员，然后Employee将是其自己的聚合根。仅涉及关系而非与人或研究相关的信息应限于此关系特定的聚合根。例如，这可以是受试者开始参加测试的开始日期，结束日期（当他退学时，如果他或她过早退学等等）。

至于存储，所有聚合根应该将它们自己的独立存储库定义为接口，并且只知道那些接口，但这些接口的实现可以自由选择使用相同的数据库或不同的数据库，甚至是不同类型的本地或因此，这适用于这些关系＆＃39;聚合根也是如此。但是，当你开始使用时，你几乎应该强迫自己使用不同的数据库，甚至是不同的技术（例如一个EntityFramework，另一个MongoDb），强迫自己确保你的接口被正确定义并独立于实现。

是的，CQRS的忠实粉丝以及事件/指挥采购也是如此。有许多轻量级的实现可以让你升级，但很容易进入并提供几乎完全线性（=可预测）的复杂性。

Answer 4

您可以从共享单一数据源的微服务开始，但仅使用部分域实体和值对象