8

例子：

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

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

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

我对此有几个问题。

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

2 回答 2

8

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

以下是我的回答：

将 AccountId 存储在学生和教师实体中是否是 DDD 中的反模式？

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

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

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

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

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

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

于 2019-06-04T17:32:14.427 回答
-2

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

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

于 2019-06-02T10:58:07.133 回答