领域驱动设计建议

Question

我有一个域，它包含以下内容：

• Venue
• Building
• Room

一个场地可以有多个建筑物，一个建筑物可以有多个房间。

我的第一个想法是把场地作为一个AggregateRoot，而大楼和房间是实体。建筑物也有一个地址，是一个ValueObject。

然后，我的第二个想法是，我需要更新一栋大楼或一间房间，而不需要经过会场。在这种情况下，有场地，建筑和房间制造的AggreagateRoots不是更好吗？还是应该这样留着呢？如果是的话，我该如何更新大楼和房间？

Answer 1

一个实体是另一个聚合下的实体还是聚合根本身的决定取决于您域的用例。

一般而言，我使用以下经验规则来确定一个实体是否应该毕业成为一个集合：

• Entity有复杂的业务规则和自己的生命周期。

具有复杂业务逻辑和自身生命周期的实体最好保持分离，以管理复杂性。

假设您域中的一个房间有许多状态、关联规则和权限结构( Manager可以在房间上执行操作，但是前台助理不能)。在这种情况下，最好将其作为一个集合。

需要直接访问和操作

• Entity ()

当您感到正在加载聚合时，除了访问实体之外，没有其他原因，它们作为独立的元素可能会更好。

• Entity及其聚合不需要共享事务边界。

如果没有将实体绑定到聚合的业务规则，则将其升级为聚合根更容易。

相反，当在聚合和其实体之间存在不变量时，而这些不变量最终不能一致，则需要将该实体封装在聚合下，并仅通过聚合操作该实体。。

• At时，实体可以独立存在，而不依赖于。

例如，您想要管理建筑物，而不必担心场地，因为您正在转租场馆的一部分。

• Enclosing聚合下的实体导致性能问题

请记住，集合不是延迟加载的；它们是完整加载的，以保证不变量保持满意。如果您的建筑物有1000多个房间，则每次加载建筑物聚合时都会使用更多的内存。

相反，请记住，通过将实体作为聚合(强大的约束)分离出来，就不能再满足不变量。您将不得不满足于最终的一致性和管理工作流，您可能会发现问题，同时使领域最终一致。

Answer 2

如果你把你的概念建模为一个集合，你就不能再引用一个房间或一个建筑了。这些将被视为场地的内部状况。您应该实现一个VenueRepository，但不应该实现BuildingRepository或RoomRepository。修改一个房间必须被看作是对场地一部分的修改。因此，您必须从存储库中检索场馆，并导航到房间进行更改，然后保存该场所的新状态。此外，外部环境必须不提及房间或建筑物，而只提及整个地点。这需要一些非常具体的用例才有意义。

你的建筑物有地址的事实是一个很好的暗示，它不可能是一个聚集内的非根实体。你完全可以想象你的建筑在原地不动，同时破坏你的场地，制造另一座建筑，在此过程中改变建筑物的地址。房间更棘手。没有建筑物，房间是不可能存在的，因此两者之间有着紧密的联系。总的来说，您是否应该将房间设置为建筑物-房间集合的一部分，还是独立的实体取决于您想要建模什么，以及您希望在您的系统中实施哪些业务约束。

设想一下，你有一条商业规则，规定:如果一栋建筑有超过5间房间，每个房间的设备价值超过10万欧元，你需要一名高管批准该大楼的电力停工。你需要在房间层为你的建筑建模，但你并不需要随机访问每一栋楼。这是因为你只是在执行建筑层面的规则。在这种情况下，您可以使用聚合。如果您正在构建一个工具来帮助人们在一个房间内安排会议，那么您需要将会议室作为会议的实体来参考。