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

Question

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

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

现在我将有几个实体，例如教授，学生，办事员。我也将与用户的身份上下文。

的问题是:如何将身份域的用户与核心域的用户之间的点连接起来?

教授将使用ProfessorID VO，学生将以StudentID VO和clerk ClerkID VO作为ID。现在用户将拥有UserID，但用户可以是学生或教授或文员。

--我是否需要在我的实体(学生、教授、职员)上放置userID，这样我才能连接到用户帐户？它似乎将应用程序的关注点推入了领域，在域中根本没有用户的概念。。

的其他想法是为用户和特定实体类设置相同的ID。例如，当学生创建其帐户时，应用程序生成一个ID，创建一个具有此ID的学生和一个具有相同ID的用户。这似乎也很奇怪。

非常感谢你的帮助！)

Answer 1

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

考虑到这一点，无论用户ID具体居住在哪里，每个更具体的模型，比如学生、教授和诸如此类的东西，都应该处理它下面的特定业务规则、业务定义和biz逻辑，而不是更通用的用户。这样，人们就可以更好地理解系统中存在的多个规范模型，从而更容易被人们和你正在构建的生态系统所理解。

至于与持久化层的连接，我认为这是DDD领域中不那么核心的东西，因为您可以应用任何对您有意义的体系结构模式，不管是MVC模式还是诸如活动记录、存储库模式等设计模式。

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

Answer 2

我倾向于说，用户的概念可能只在登录和可能用于配置文件管理的上下文中有用:该配置文件可以包括将用户与域角色相关联(即，该用户具有该教授ID)。