我是DDD的新手，我需要一些帮助。
示例：
我有两个有界上下文Exams和Courses。考试上下文有一个Student实体，其中包含有关参加考试的学生的信息。而且“课程”上下文具有一个教师实体，其中包含有关教授课程的信息。
我还有一个AuthService，用于用户的身份验证和授权。 AuthService有一个Accounts实体，其中包含诸如帐户用户的姓名，地址，电话号码等信息。
将它们全部合并在一起，Student和Teacher都具有帐户，因此它们的信息已经可用。
对此我有几个问题。
答案 0 :(得分：5)
我假设AuthService处于其指定的用于身份验证的有界上下文中，并且Accounts也处于该相同的有界上下文中。
这是我的答案：
在DDD中将AccountId存储在Student中是反模式吗？ 教师实体？
您可以将AccountId存储在Student和Teachers实体中。这不是反模式，而是相反的-这是通过保留其他集合的ID来实现不同集合相互引用的方式。
如果在什么时候不是反模式，可以 使用以下帐户ID收集学生的帐户信息 存储库或API控制器中，还是我们应该使用RPC / API调用。
对于帐户，学生或教师，我不明白您确切指的是哪个存储库？每个聚合根都有自己的存储库，该存储库仅负责存储这些聚合。它不知道或查询其他聚合。如果您需要查询其他有界上下文，请从应用程序层执行此操作-如果执行此操作的操作与域无关。如果是域问题，则在域层中通过将另一个有界上下文表示为域服务（接口）来执行此操作。 RPC / API是内部绑定上下文调用的实现细节，只要实现细节不会泄漏到域层中，您就可以使用任何一种方法来查询另一个有界上下文。
可以将所需的详细信息从帐户实体复制到学生或教师实体吗？
那也没关系。您这样做是为了以最终一致性为代价获得更高的可用性。在这种情况下，保存来自另一个人的信息的有限上下文/实体会承认数据副本可能会过时，但在业务术语上是可以接受的。
让我知道是否有任何问题。我是DDD的长期从业人员。
答案 1 :(得分：-1)
我认为您的方法有误。与Authentication相关的事物不应在域层中。 Student和Teacher是entity，但是Account中的AuthService不是entity。据我所知，您想使用来自Student的一些信息来添加新的Teacher或Account，但是为此，您应该通过获取{{ 1}}信息，并将它们传递给User Account或Student类以实例化新对象。
对于第二个问题，取决于我们的业务，您可能具有相同的属性。 Teacher只是强调您应使用DDD来命名实体和方法，而使用相同的属性也没关系。