DDD：持久聚合
让我们考虑一下典型的 Order 和 OrderItem 示例。假设 OrderItem 是 Order 聚合的一部分，它只能通过 Order 添加。因此，要将新的 OrderItem 添加到 Order 中，我们必须通过存储库加载整个聚合，并将新项目添加到 Order 对象中并再次保留整个聚合。
这看起来开销很大。如果我们的订单有 10 个OrderItems怎么办？这样，仅仅添加一个新的 OrderItem，我们不仅要读取 10 个 OrderItems，而且还应该重新插入所有这 10 个 OrderItems再次强>。 （这是 Jimmy Nillson 在他的 DDD 书中采用的方法。每次他想要持久化一个聚合时，他都会清除所有子对象，然后再次重新插入它们。这可能会导致其他问题，因为子对象的 ID 是由于数据库中的 IDENTITY 列，每次都会更改。）
我知道有些人可能建议在聚合根应用工作单元模式，以便它跟踪已更改的内容并仅提交这些更改。但这违反了持久性无知（PI）原则，因为持久性逻辑正在泄漏到域模型中。
以前有人考虑过这个问题吗？
莫什
Let's consider the typical Order and OrderItem example. Assuming that OrderItem is part of the Order Aggregate, it an only be added via Order. So, to add a new OrderItem to an Order, we have to load the entire Aggregate via Repository, add a new item to the Order object and persist the entire Aggregate again.
This seems to have a lot of overhead. What if our Order has 10 OrderItems? This way, just to add a new OrderItem, not only do we have to read 10 OrderItems, but we should also re-insert all these 10 OrderItems again. (This is the approach that Jimmy Nillson has taken in his DDD book. Everytime he wants to persists an Aggregate, he clears all the child objects, and then re-inserts them again. This can cause other issues as the ID of the children are changed everytime because of the IDENTITY column in database.)
I know some people may suggest to apply Unit of Work pattern at the Aggregate Root so it keeps track of what has been changed and only commit those changes. But this violates Persistence Ignorance (PI) principle because persistence logic is leaking into the Domain Model.
Has anyone thought about this before?
Mosh
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这不一定是问题，一些 ORM 支持惰性列表。
例如
您可以加载订单实体并将项目添加到详细信息集合中，而无需实际具体化该列表中的所有其他实体。
我认为 N/Hibernate 支持这一点。
如果您正在编写自己的实体持久性代码而不使用任何 ORM，那么您就很不走运，您将不得不重新实现与 ORMappers 免费提供的相同的脏跟踪机制。
This doesn't have to be a problem, some ORM's support lazy lists.
e.g.
You could load the order entity and add items to the Details collection w/o actually materializing all of the other entities in that list.
I think N/Hibernate supports this.
If you are writing your own entity persistence code w/o any ORM, then you are pretty much out of luck, you would have to re-implement the same dirty tracking machinery as ORMappers give you for free.
整个聚合必须从数据库加载，因为 DDD 假定聚合根确保聚合边界内的一致性。为了检查这些规则，必须加载所有必要的数据。如果要求特定客户的订单价值不能超过 100000 美元，则聚合根（订单）必须在持久更改之前检查此规则。这并不意味着必须加载所有现有项目并将其价值相加。订单可以维护现有项目的预先计算的总和，该总和在添加新项目时更新。通过这种方式检查业务规则只需要在添加新项目时加载订单数据。
The entire aggregate must be loaded from database because DDD assumes that aggregate roots ensure consistency within boundaries of aggregates. For these rules to be checed, all necessary data must be loaded. If there is a requirement that an order can be worth no more then $100000 for particular customer, aggregate root (Order) must check this rule before persisting changes. This does not imply that all the exisiting items must be loaded and their value summed up. Order can maintain pre-calculated sum of existing items which is updated on adding new ones. This way checking the business rule requires only Order data to be loaded when adding new items.
我对这种方法不是 100% 确定，但我认为应用工作单元模式可能是答案。请记住，在应用程序或域服务中应该完成任何事务，您可以使用已更改的聚合中的对象来填充工作单元类/对象。之后让 UoW 类/对象发挥作用（当然，在某些情况下构建适当的 UoW 可能很困难）
以下是来自 此处：
I'm not 100% sure about this approach , but I think applying unit of work pattern could be the answer . Keeping in mind that any transaction should be done , in application or domain services , you could populate the unit of work class/object with the objects from the aggregate that you have changed . After that let the UoW class/object do the magic (ofcourse building a proper UoW might be hard for some cases)
Here is a description of the unit of work pattern from here :