1

我可以使用一些帮助来理解我的域模型并确保我正确地接近设计。

我有一个名为 Department 的聚合根。Department 对象有几个子值类型，有助于定义“部门”的业务概念。在我的 UI 中，用户可以列出、创建、编辑和删除部门对象。

我有另一个名为 Project 的聚合根。一个项目有几个子值类型，但也与一个部门有关系，因为每个项目都由一个部门“拥有”。可以创建、编辑、删除项目等，这样做对部门没有影响，而删除部门也会删除它拥有的任何项目。

我的 UI 将根据当前用户有权访问的部门显示项目列表。他们可能能够访问多个部门。当同时显示为列表项和详细信息时，我需要在项目中显示部门徽标。

我的第一个想法是 Project 是一个聚合根，具有一个简单的 DepartmentID 属性，可用于“查找”部门。但现在我开始认为我真的只有一个总根：部门。

你怎么看？

更新

我不知道这是否是讨论的关键或改变了什么，但在阅读前几个答案后我想到了以下想法。

部门似乎有两种情况：

  1. 作为支持修改的独立实体。
  2. 作为 Project 的子项，在这种情况下包含只读数据且没有行为。

这让我认为我的模型中应该有两个“对象”，一个用于案例 #1 的聚合根和一个用于案例 #2 的值类型。我在正确的轨道上吗？

4

3 回答 3

1

由于没有部门就无法存在项目，因此它可能不是聚合根。根据您的描述，听起来您只有一个 AR - 部门，用于管理其中的项目。

如果您的行为主要是 CRUD，我不建议为它构建一个完整的域模型，因为您可能可以采用更简单的方法。

更新 正如您所提到的，您可能在这里有 2 个有界上下文。一个部门是一个 AR，项目是这个 AR 的实体。在这种情况下，您将对您的部门执行操作。在第二个 BC 中，您的项目可能是 AR，部门可能是实体或 VO。这将允许您直接处理项目。

我还建议您与您的领域专家一起研究一下，看看这些概念是否适合您的 UL，或者搜索一些可以澄清您的模型的缺失概念。我会特别寻找一个可以将项目与部门联系起来的概念。

于 2011-05-20T08:43:49.753 回答
1

我认为将 Project 和 Department 都作为聚合根是完全合理的，因为它们都是独立管理的。

也就是说，每个项目和每个部门都有某种唯一标识符，虽然您可以将项目添加到部门，但项目本身可能已经足够复杂（具有自己的生命周期、自己的子对象等）以保证聚合根状态。

您只需要在每个项目中保留对部门的引用即可。

于 2011-05-20T11:50:08.180 回答
0

几个简单的问题需要回答：

1）没有Project域对象，部门域对象能否独立存在。- 如果是，那么部门是一个集合。

2) Project 域对象是否可以独立存在 - 如果是，那么 Project 也是一个聚合

3) 项目是否与一个部门有关系 - 那么它应该是作为物业部门公开的项目聚合的一部分

4) 部门是否与一个或多个项目对象有关系 - 项目聚合应该是部门聚合对象的一部分。

因此，使用 Department 聚合对象，您可能需要访问 Project(s) 对象的列表，一旦您拥有 Project 对象，您可能需要访问 Department 对象。这是一个过时的循环引用。

这是一个典型的例子，员工有一个经理，经理有一个员工列表

于 2011-05-20T23:11:13.387 回答