包含过多信息的实体的 DDD答案

【问题标题】：DDD with entities that contain too much information包含过多信息的实体的 DDD
【发布时间】：2019-10-09 18:18:00
【问题描述】：

我决定将我最近学到的有关 DDD 的知识付诸实践，但我对在我的场景中要做什么感到困惑。我对这个学派很陌生，所以请原谅我的无知

考虑以下几点：

School 有 30 个属性，包括在那里工作的教师的时间序列和时间，以及校长的时间序列。它还有一个时间序列Classroom
Classroom 有另外 20 个属性。还有历年教室颜色的时间序列、座位布置方式等。还有StudentAttendance记录历史（30年时间序列）
StudentAttendance 记录具有 Year 和 NumberOfStudents (ValueObject)

你如何定义这个模型？

我最初的想法是，学校就是 AR，因为没有学校就不可能有教室，没有教室就不可能有 StudentAttendance。

我的问题是，为了更改随机的StudentAttendance 记录的NumberOfStudents（假设 1993 年的 SchoolId 10, Classroom 1 有 25 名学生而不是 30 名），我是否需要创建一个 valid School 第一个？这意味着我需要获取大量信息来填充我的操作不需要的所有其他属性。我基本上只需要 schoolId、classroomId、年份和新号码。

在旧的 CRUD 世界中，我只会定义一个方法
UpdateStudentAttenance(int schoolId, int classroomId, int year, int newNumberOfStudents)

注意：根据 DDD，我创建了具有填充所有属性的构造函数的类，以创建并保持它们处于有效状态（例如 School 必须 Name、Area、ConstructionYear 等）所以我不能只打电话给new School(id: 5)

【问题讨论】：

标签： domain-driven-design

【解决方案1】：

您的域中可以有多个学校或教室（或任何其他实体）。这里的关键是有界上下文（BC）隔离。每个 BC 都有自己的学校，只有对这个 BC 很重要的属性。每个 BC 中重要的属性取决于域操作和完成操作所需的信息。此规则也适用于 VO 和聚合。

即：

您定义了 3 个产品实体。一个在 Warehouse BC，一个在 Marketing BC，一个在 Store BC。由于 Warehouse BC 仅具有与库存、供应、运输等相关的域操作； Warehouse 的 Product 实体不需要 Customer Price 属性。

而且不仅在不同的 BC 中有几个相同的事物（实体、VO 或 AG）。您还可以拥有相同的领域概念（学校、教室等），它们在其中扮演不同的角色每个参与其中的BC。学校可以是一个 BC 中的实体，另一个 BC 中的聚合根和第三个 BC 中的 VO。每个都有自己的实现，有自己的约束、方法、属性等。

使用 DDD 进行设计的最佳方式是考虑域操作。您的所有领域设计都必须围绕领域操作以及完成这些操作所需的信息。

另请注意，如果您的系统中没有明确意图的流程工作流（即仅更新 NumberOfStudents 以修复错误并且不存在附带影响），则不需要 DDD，您只需要 CRUD，它是在系统的某些部分使用 DDD 而在另一部分使用 CRUD 并没有错。

这个答案也可以帮助你的设计：Aggregate or entity without business attributes

【讨论】：