Architecture 域驱动设计-标识域和核心域持久性问题

我开始学习DDD，并开始开发一个简单的应用程序来处理大学论文。其思路如下：

学生写论文，然后需要答辩才能完成课程（学士、硕士等）。教授需要修改一篇论文，给出分数和评论，然后进行考试，学生需要为自己的论文辩护。每门课程都有独立的论文，学生可以在大学选修一门以上的课程。 学生将拥有自己的账户，以添加书面论文，教授将审查论文并给出分数，院长办公室的职员将设置论文答辩等

现在我将有几个实体，例如教授、学生、职员。我还将与用户建立身份上下文

问题是：如何将身份域用户与核心域实体（建模持久层）之间的点连接起来？

教授将有ProfessorID VO，学生将有StudentID VO和Clerk ClerkID VO作为ID。现在用户将有UserID，但用户可以是学生、教授或职员

我是否需要在我的实体（学生、教授、职员）上添加userID，以便与用户帐户建立某种连接？这似乎将应用程序关注点推向了一个根本没有用户概念的领域。

另一个想法是为用户和特定实体类提供相同的ID。例如，当学生创建帐户时，应用程序生成一个ID，创建一个具有此ID的学生和具有相同ID的用户。这看起来也很奇怪。

---

非常感谢您的帮助！：）

DDD警告我们的一个概念是规范模型；这基本上意味着拥有一种官方认可的可信和权威的公共语言，在域模型的用户（域专家）和开发人员（技术专家）之间共享。问题是，这种模式可能会发展到几乎没有人能理解的规模

考虑到这一点，无论用户ID具体位于何处，每个更具体的模型（如学生、教授等）都应该处理其下的特定业务规则、业务定义和业务逻辑，而不是更一般的用户。这样，人们就可以更好地了解系统中存在的多个规范模型，这些模型更容易为人们和您正在构建的生态系统所理解

至于与持久性层的连接，我认为这不是DDD领域的核心，因为您可以应用任何对您有意义的架构模式，无论是MVC还是设计模式，如活动记录、存储库模式等

---

一个值得尝试的很酷的练习是上下文映射，它允许您将“事物”视为名词和动词/事件。

我倾向于说，用户的概念可能只在登录等上下文中有用，也可能用于配置文件管理：该配置文件可能包括将用户与域角色关联（即，此用户具有此教授ID）.

是的，域类将处理业务逻辑，但与特定用户连接的身份验证和授权将存在于应用层。但问题是：如果我在域类上存储用户ID，这会是一种糟糕的设计吗？还是我应该坚持在用户上使用与域类相同的ID（这当然不是域的一部分，但我需要以某种方式保持所有这些）