我开始了解 DDD，并开始开发一个处理大学论文的简单应用程序。思路如下：
学生写了一篇论文，然后需要通过答辩才能完成课程（学士、硕士等）。 3位教授需要修改论文给出成绩和评论，之后是考试，学生需要对他/她的论文进行答辩。每门课程都有单独的论文，学生可以在大学修读多门课程。 学生有自己的账户添加论文，教授审查论文并评分，院长办公室文员进行论文答辩等。
现在我将有几个实体，例如教授、学生、文员。我还将与用户建立身份上下文。
问题是：我如何将身份域中的用户与我的核心域中对持久层建模的实体连接起来？
Professor 将有 ProfessorID VO，Student 将有 StudentID VO 和 Clerk ClerkID VO 作为 ID。现在用户将拥有 UserID，但用户可以是学生、教授或文员。
我是否需要将用户 ID 放在我的实体（学生、教授、文员）上，以便我与用户帐户建立某种联系？这似乎是将应用程序问题推到了领域中，在那里根本没有用户的概念。
其他想法，是用户和特定实体类具有相同的 ID。例如，当学生创建其帐户时，应用程序会生成一个 ID，使用此 ID 创建一个学生和具有相同 ID 的用户。这看起来也很奇怪。
非常感谢您的帮助！ :)
答案 0 :(得分：0)
DDD 警告我们的概念之一是规范模型；这基本上意味着拥有一种官方认可的真实和权威的通用语言，在领域模型的用户（领域专家）和开发人员（技术专家）之间共享。问题在于，这个模型可以增长到几乎无人能理解的大小。
考虑到这一点，无论用户 ID 位于何处，每个更具体的模型（例如学生、教授等）都应该处理其下的特定业务规则、业务定义和业务逻辑，而不是更通用的用户.这样一来，人们就可以更好地了解系统中存在的多个规范模型，人们和您正在构建的生态系统可以更轻松地理解这些模型。
至于与持久层的连接，我认为它不是 DDD 领域的核心，因为您可以应用任何对您有意义的架构模式，无论是 MVC 还是诸如 Active Record、Repository 模式等设计模式.
值得尝试的一项很酷的练习是上下文映射，它可以让您将“事物”视为名词和动词/事件。
答案 1 :(得分：0)
我倾向于说用户的概念可能仅在登录等上下文中有用，并且可能用于个人资料管理：该个人资料可能包括将用户与域角色相关联（即该用户具有此教授 ID）。< /p>