Domain driven design 包含太多信息的实体的DDD

我决定将我最近学到的DDD应用到实践中，但我对在我的场景中应该做什么感到困惑。我对这个学派很陌生，请原谅我的无知

考虑以下几点：

• 学校

  有30个属性，包括在那里工作的教师的时间序列和校长的时间序列。它还有一个

  教室的时间序列

• 教室

  还有20个属性。此外，历年教室颜色的时间序列、座位的安排方式等。它还具有

  学生注意力

  记录历史（30年的时间序列）

• StudentAttendence

  记录具有

  年份

  和

  学生人数

  （ValueObject）

你如何定义这个模型

我最初的想法是，学校就是AR，因为没有学校，教室就不可能存在，没有教室，学生的注意力也不可能存在。

我的问题是，为了改变一个随机的

学生出席人数

记录的

学生人数

（假设1993年的SchoolId 10，教室1有25名学生，而不是30名学生），我是否需要先创建一个有效的

学校

？这意味着我需要获取大量信息来填充我的操作不需要的所有其他属性。 我基本上只需要学校ID、教室ID、年份和新号码。

在旧的CRUD世界中，我只需要定义一个方法

updatestudentattentiance（int schoolId，int classroomId，int year，int newNumberOfStudents）

---

注意：根据DDD，我已经创建了包含构造函数的类，这些构造函数填充了所有属性，以创建并保持它们处于有效状态（例如

学校
必须
有
名称
，
区域
，
建设年
等），因此我不能直接调用
新学校（id:5）
您可以在您的域中拥有多个学校或教室（或任何其他实体）。这里的关键是有界上下文（BC）分离。每个不列颠哥伦比亚省都有自己的学校，只有对这个不列颠哥伦比亚省重要的财产。每个BC中重要的属性取决于域操作和完成操作所需的信息。此规则也适用于VO和聚合

i、 e:

您定义了3个产品实体。一个在仓库BC，一个在营销BC，一个在商店BC。因为仓库BC只有与库存、供应、运输等相关的域操作；仓库的产品实体不需要Customer Price属性

而不仅仅是不同BC中的几个相同的东西（实体、VO或AG）。您还可以拥有相同的领域概念（学校、教室等），这些概念在应用程序中扮演不同的角色
涉及的每一个BC。学校可以是一个BC中的实体，另一个BC中的聚合根和第三个BC中的VO。每一个都有自己的实现，有自己的结构、方法、属性等

使用DDD进行设计的最佳方法是考虑域操作。你所有的domian设计都必须围绕域操作和完成这些操作所需的信息

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

此答案也有助于您的设计：