定义边界并在聚合根之间进行通信
我可以使用一些帮助来理解我的领域模型，并确保我正确地进行设计。
我有一个名为 Department 的聚合根。 Department 对象有多个子值类型，可帮助定义“部门”的业务概念。在我的 UI 中，用户可以列出、创建、编辑和删除部门对象。
我有另一个名为 Project 的聚合根。项目有多个子值类型，但也与部门有关系，因为每个项目都由部门“拥有”。可以创建、编辑、删除项目等，这样做对部门没有影响，而删除部门也会删除其拥有的任何项目。
我的 UI 将根据当前用户有权访问的部门显示项目列表。他们可能能够访问多个部门。当显示为列表项和详细信息时，我需要在项目中显示部门徽标。
我的第一个想法是该项目是一个具有简单 DepartmentID 属性的聚合根，可用于“查找”部门。但现在我开始认为我实际上只有一个聚合根：部门。
你怎么认为？
更新
我不知道这是否是讨论的关键或改变了什么，但在阅读前几个答案后，我想到了以下想法。
部门似乎有两个背景：
- 作为一个独立的实体， 支持修改。
- 作为一个项目的子项目，其中 case 包含只读数据并且 没有行为。
这让我认为我的模型中应该有两个“对象”，案例#1 的聚合根和案例#2 的值类型。我走在正确的轨道上吗？
I could use some help understanding my domain model a bit and making sure I am approaching the design correctly.
I have an aggregate root called Department. The Department object has several child value types that help define the business notion of a 'department.' In my UI users can list, create, edit and delete Department objects.
I have another aggregate root called Project. A Project has several child value types but also has a relationship to a Department in that each Project is 'owned' by a department. Projects can be created, edited, deleted, etc. and doing so has no impact on the department whereas removing a Department also removes any projects it owns.
My UI will display a list of Projects based on the departments the current user is authorized to access. They may be able to access more than one department. When displayed as both a list item as well as in detail, I need to show the Department logo with the Project.
My first thought was the Project was an aggregate root with a simple DepartmentID property that could be used to 'lookup' the Department. But now I'm starting to think that I really only have one aggregate root: Department.
What do you think?
UPDATE
I don't know if it is key to the discussion or changes anything but the following thought occurred to me after reading the first couple of answers.
Department appears to have two contexts:
- As a stand-alone entity that
supports modification. - As a child of a Project in which
case is contains read-only data and
no behavior.
This makes me think that I should have two 'objects' in my model, an aggregate root for case #1 and a value type for case #2. Am I on the right track?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
由于项目不能没有部门而存在，因此它可能不是聚合根。从您的描述来看，您似乎只有一个 AR - 部门，您用它来管理内部的项目。
如果您的行为主要是 CRUD，我不建议为其构建完整的域模型，因为您可能可以采取更简单的方法。
更新
正如您所提到的，您可能在这里有 2 个有界上下文。其中部门是 AR，项目是该 AR 的实体。在这种情况下，您将对您的部门执行操作。在第二个 BC 中，您的项目可能是 AR，部门可能是实体或 VO。这将允许您直接处理项目。
我还建议与您的领域专家一起讨论这个问题，看看这些概念是否适合您的 UL，或者寻找一些缺失的概念来阐明您的模型。我特别会寻找一个可以将项目与部门联系起来的概念。
Since the Project can't exist without a Department it's probably not an Aggregate Root. From your description it sounds like you only have one AR - the Department, which you use to manage the projects inside it.
If your behavior is mostly CRUD, i would not recommend building a full blown domain model for it since there are probably simpler approaches you can take.
UPDATE
As you mention, you might have 2 bounded contexts here. One where the Department is an AR and the Projects are entities of this AR. In this context you would perform operations on your Departments. In a second BC your Project could be the AR and the Departments could be entities or VOs. This would allow you to work directly with projects.
I would also recommend going over this with your domain expert and see if these concepts fit well in your UL, or maybe search for some missing concept that can clarify your model. I would especially look for a concept that might link projects to departments.
我认为将项目和部门都作为聚合根是完全合理的，因为它们都是独立管理的。
也就是说，每个项目和每个部门都有某种唯一标识符，虽然您可以将项目添加到部门，但项目本身可能足够复杂（具有自己的生命周期、自己的子对象等）以保证聚合根状态。
您只需在每个项目中保留对部门的引用即可。
I think it's perfectly defensible to have both Project and Department be aggregate roots, since they are both managed independently.
That is, every Project and every Department have some kind of unique identifier, and while you can add Projects to Departments, Projects themselves are probably complicated enough (with their own lifecycles, their own child objects etc.) to warrant aggregate root status.
You just have to keep a reference to the Department in each Project.
有几个简单的问题需要回答：
1）部门域对象可以在没有项目域对象的情况下独立存在吗？ - 如果是，则该部门是一个集合。
2) 项目域对象是否可以独立存在 - 如果是，则项目也是一个聚合
3) 项目是否与一个部门有关系 - 那么它应该是作为属性部门公开的项目聚合的一部分
4) 是部门与一个或多个项目对象有关系 - 项目聚合应该是部门聚合对象的一部分。
因此，使用 Department 聚合对象，您可能需要访问 Project(s) 对象列表，并且一旦拥有 Project 对象，您可能需要访问 Department 对象。这是一个循环引用，但已经过时了。
这是一个典型的例子：员工有经理，经理有员工列表
Few simple questions to be answered:
1) can the department domain object live by its own without the Project domain object. - If yes, then the department is an aggregate.
2) Is the Project domain object can live by its own - If yes, then the Project is also an aggregate
3) Is Project has relationship with one Department - Then it should be part of the Project aggregate exposed as property Department
4) Is Department has relation ship with one or more Project objects - The the Project aggregate should be part of the Department aggregate object.
So, Using Department aggregate object you might need to access the list of Project(s) object and once you have the Project object you might need to access the Department object. It is a circular reference which is obsoletely fine.
It is a typical example of Employee has a manager and manager has a list of employees