如何在 DDD 中组合来自不同限界上下文的数据答案

【问题标题】：How to Combine Data From Different Bounded Context in DDD如何在 DDD 中组合来自不同限界上下文的数据
【发布时间】：2019-10-13 23:25:28
【问题描述】：

例子：

我有两个有界上下文Exams 和Courses。 Exams 上下文有一个Student 实体，其中包含有关参加考试的学生的信息。 Courses 上下文有一个教师实体，其中包含有关教授课程的教师的信息。

我还有一个AuthService（纯CRUD），用于用户的身份验证和授权。 AuthService 有一个 Accounts 实体，其中包含帐户用户名、地址、电话号码等信息。

将它们放在一起，Student 和 Teacher 都有帐户，因此他们的信息已经可用。

我对此有几个问题。

在 DDD 中将 AccountId 存储在 Student 和 Teachers 实体中是否是反模式？如果不是反模式，那么什么时候可以使用 AccountId、In repository 或 API 控制器收集学生帐户信息，或者我们应该使用 RPC/API 调用。
是否可以将所需的详细信息从 Account 实体复制到 Student 或 Teacher 实体？

【问题讨论】：

标签： oop asp.net-core domain-driven-design ddd-service

【解决方案1】：

我认为你走错路了。与Authentication 相关的东西不应该在域层中。 Student 和 Teacher 是 entity，但 AuthService 中的 Account 不是 entity。据我所知，您想通过使用来自Account 的一些信息来添加新的Student 或Teacher，但为此您应该通过获取User Account 信息来传递此信息并将它们传递给Student 或 Teacher 类来实例化一个新对象。

对于您的第二个问题，取决于我们的业务，您可能拥有相同的属性。 DDD 只是强调你应该使用ubiquitous language 来命名实体和方法，使用相同的属性并不重要。

【讨论】：

身份验证纯粹是 CRUD
是的，我知道，但所有有 CRUD 的东西都不是 entity。你的业务是不同的。您正在编写身份验证服务吗？我不这么认为。这只是一种通常用于基础设施层的身份验证工具。
@AliSoltani 我认为您将域层与核心域混淆了。
虽然身份验证服务可能主要是行为，但支持数据存储在“某处”。 Account 将成为一个实体，Student 和 Teacher 作为不同的角色。 Student 和 Teacher 在一天结束时可以简单地成为 DTO；有不止一种方法可以对此进行建模。我认为@AliSoltani 在他的脑海中指的是 API 调用期间的身份验证方面。这是应用层的问题，不属于域。
@SubhashBhushan 是的，认证可能不是当前域的意图，但它可以是另一个指定的认证相关域的意图。这正是我的评论的意思 - 身份验证可能属于域层，但可能不属于核心域，假设身份验证不是我们正在查看的业务的核心（也许是）。

【解决方案2】：

我假设 AuthService 在其指定的有界上下文中进行身份验证，并且 Accounts 也在同一个有界上下文中。

这是我的答案：

在 DDD 中将 AccountId 存储在 Student 和教师实体？

您可以将 AccountId 存储在 Student 和 Teachers 实体中。这不是一种反模式，而是相反的模式——这就是不同的聚合如何相互引用，通过保持其他聚合的 Id。

如果不是反模式，什么时候可以使用 AccountId 收集学生帐户信息，在存储库或 API 控制器中，或者我们应该使用 RPC/API 调用。

我不明白您的确切意思是帐户、学生还是教师的存储库？每个聚合根都有自己的存储库，并且该存储库仅负责存储这些聚合。它不知道或查询其他聚合。如果您需要查询其他有界上下文，请从应用程序层执行此操作 - 如果执行此操作的操作不是域关注的。如果这是一个域问题，那么在域层中通过将另一个有界上下文表示为域服务（接口）来执行此操作。 RPC/API 是绑定上下文调用的实现细节，您可以使用任何一种方式来查询另一个绑定上下文，只要实现细节不泄漏到域层中。

是否可以将所需的详细信息从 Account 实体复制到 Student 或 Teacher 实体？

那也没关系。您这样做是为了以最终一致性为代价实现更高的可用性。在这种情况下，保存来自另一个人的信息的有界上下文/实体承认数据副本可能会过时，但业务条款可以接受。

如果有任何问题，请告诉我。我是一名长期的 DDD 从业者。

【讨论】：