我将我的系统分成（至少）两个有界上下文：研究设计和调查计划。
在研究设计上下文中有一个名为“主题”（面试的潜在主题）的概念。我们还保持该领域的受试者和人群之间的关联。
现在，在调查计划中，我们还需要关于对象的（一些）信息（例如：用于计划访问，甚至用于预期的问卷选择，以防事先知道对象所属的人群）。
所以，我在这两种情况下都需要那个“主题”。
我应该选择什么方法？拥有共享内核，如 Eric Evans DDD 书中所述？我不介意（至少现在）让两个上下文共享同一个数据库。
或者......我应该去纯微服务吗？含义：这两个不能/不应该共享数据库...，在这种情况下，我可能不得不通过事件传递走镜像/复制路线：https ://www.infoq.com/news/2014/11 /共享数据有界上下文
对于上述情况，有什么想法更好吗？
谢谢！
微服务的上下文是分布式系统。在任何其他情况下，这可能是矫枉过正。共享内核最终会分裂。通常情况就是这样。你可以从它开始。没有错。但是，它不会留在那里。
我建议你选择事件驱动的解决方案，但不一定要使用微服务。您可以构建一个事件驱动的单体，以便在同步两个模型上花费更少的时间。当应用程序变得太大时，您会将整体拆分为微服务。您可以使用 CQRS 将事件更多的模型拆分为写入和读取。如果您使用事件溯源，事情会变得更加有趣。
以我的经验，使用共享内核，模型变成了上帝的对象，一刀切的对象。
在我看来，你有三个实体：
很直观地看到，每一个都是它自己的聚合根。因此，我们正在谈论根间关系。根据我的经验，它们本身就是有意义的实体，到目前为止，最清晰和最未来的证明是将这些关系视为独立的聚合根。
一项研究与一个人之间的关系可能称为 TestSubject，而一个人与一项调查之间的关系可以称为受访者或类似的东西。在另一种情况下，该人可能是公司的员工，然后员工将是其自己的聚合根。仅与关系有关而不与人或研究有关的信息应限于此关系特定的聚合根。例如，这可能是受试者开始参加测试的开始日期和结束日期（他或她退出的时间，如果他或她过早退出等）
至于存储，所有聚合根都应该定义自己独立的存储库作为接口，并且只知道那些接口，但是这些接口的实现可以自由选择使用相同的数据库或不同的数据库，甚至不同种类，本地或分布式等. 所以这也适用于这些“关系”聚合根。但是你几乎应该强迫自己使用不同的数据库，甚至最好使用不同的技术（例如，一个 EntityFramework，另一个 MongoDb），以确保你的接口被正确定义并且独立于实现。
是的，这里也是 CQRS 的忠实粉丝，以及事件/命令采购。有许多轻量级实现可能允许您进行升级，但很容易进入并为您提供几乎完全线性（=可预测）的复杂性。
您可以从共享单一数据源的微服务开始，但仅使用部分域实体和值对象