我读过这篇文章，这让我三思而后行……：
“避免工作单元模式。聚合根应定义事务边界。”
为什么有人应该避免应用领域驱动设计的 UOW 模式？
问问题
14166 次
3 回答
32
（在我的帖子之前，我建议阅读V. Vernon 的“实施领域驱动设计”一书的这一章。它可以帮助您接近聚合并包含对您问题的长答案。）
在一个设计合理的系统中，一个命令一次更改一个聚合，每个聚合都有边界，这些边界由聚合根中的不变量定义。因此，当您对聚合进行任何更改时，将检查不变量并在一个事务中应用（或不应用）更改。这是事务一致性。你需要在这里使用工作单元吗？不要这么想。
但我们经常会遇到一次需要更改多个聚合的情况。事务变得更大，它们涉及的不仅仅是系统的一部分，我们谈论的是最终一致性。在这种情况下，UoW 是一个很好的帮手。
正如在没有上下文的情况下提到的那样，很难猜测作者在想什么，但我想他讲述了事务一致性案例。在分布式系统中，您将需要使用诸如 UoW 之类的东西来为系统提供最终的一致性。
于 2013-02-05T08:33:24.387 回答
6
基本上，根据M. Fowler的说法，UoW “只是”一种智能持久性工具（无论此任务可能多么复杂）。所以恕我直言，与 DDD 方法没有内在的不兼容性，它为您的域建模的“精神”提供了更多指导，而不是技术工具。
没有上下文，很难说出引文的作者在想什么。但也许他写这个是因为在使用 UoW 时，通常很难让您的实体管理自己的生命周期（以及其他人的生命周期），通常具有持久性和事务行为。
事实上，可以在带有AOP的 DDD 风格的应用程序中使用 UoW 模式。使用这种工具，可以保持 DDD 精神，以实体为中心，具有业务能力的领域模型，同时利用复杂但业务正交的机制来实现适当的事务持久性。
通常，在 Java 世界中，您可以在 DDD 应用程序中使用：
- Hibernate/JPA as a UoW ：提供域模型实体的“智能持久性”（也可能是 JPA @Entity ）
- Spring AOP + AspectJ ：在实体中提供DI
- Spring TX + AspectJ：在您的实体中启用事务方法
这些提供了 DDD 就绪（和大量@nnotated ;]）实体。
于 2013-02-04T23:30:06.237 回答
1
首先，聚合是一个对象，用于保存一组加载实体，用于应用命令。
- 实体可以属于许多不同的聚合。
- 每个命令只能与一个聚合通信，该聚合应该包含命令所需的所有实体。
- 聚合可以在命令之间重用。
“工作单元”基本上是动态聚合，允许对一组实体进行单个事务更新，而无需在代码中明确定义聚合来执行此操作。
这是以没有明确的 Aggregate 类为代价的，在该类上放置保护不变量的突变方法。
投票最多的答案包含：
但我们经常会遇到一次需要更改多个聚合的情况。事务变得更大，它们涉及的不仅仅是系统的一部分，我们谈论的是最终一致性。在这种情况下，UoW 是一个很好的帮手。
这是荒谬的，因为根据定义，聚合是事务所需的一组内容。如果您发现您“需要来自两个不同聚合的实体”，那么实际上您需要的是“定义一个包含对所需实体的引用的附加聚合”。
于 2021-02-11T13:21:37.803 回答