避免领域驱动设计中的工作单元模式答案

【问题标题】：Avoid Unit of Work pattern in domain driven design避免领域驱动设计中的工作单元模式
【发布时间】：2013-01-19 17:35:05
【问题描述】：

我读过这篇文章，这让我三思而后行……：

“避免工作单元模式。聚合根应定义事务边界。”

为什么有人应该避免应用领域驱动设计的 UOW 模式？

【问题讨论】：

【解决方案1】：

基本上，根据M. Fowler 的说法，UoW “只是”一种智能持久性工具（无论此任务可能多么复杂）。所以恕我直言，与 DDD 方法没有内在的不兼容性，它为您的域建模的“精神”提供了更多指导，而不是技术工具。

没有上下文，很难判断引文作者的想法；但也许他写这篇文章是因为在使用 UoW 时，通常很难让您的实体管理自己的生命周期（以及其他人的生命周期），通常是持久性和事务性行为。

事实上，AOP 可以在 DDD 风格的应用程序中使用 UoW 模式。使用这种工具，可以保持 DDD 精神，使用以实体为中心、具有业务能力的领域模型，同时利用复杂但业务正交的机制来实现适当的事务持久性。

通常，在 Java 世界中，您可以在 DDD 应用中使用：

这些提供了 DDD 就绪（和大量@nnotated ;]）实体。

【讨论】：

【解决方案2】：

（在我的帖子之前，我建议阅读 V. Vernon 的“实施领域驱动设计”一书的 this chapter。它可以帮助您接近聚合并包含对您问题的长答案。）

在一个设计合理的系统中，一个命令一次更改一个聚合，每个聚合都有边界，这些边界由聚合根中的不变量定义。因此，当您对聚合进行任何更改时，会检查不变量并在一个事务中应用（或不应用）更改。这是事务一致性。你需要在这里使用工作单元吗？不要这么认为。

但我们经常会遇到一次需要更改多个聚合的情况。事务变得更大，它们涉及的不仅仅是系统的一部分，我们谈论的是最终一致性。在这种情况下，UoW 是一个很好的帮手。

正如在没有上下文的情况下提到的那样，很难猜测作者在想什么，但我想他讲述了事务一致性案例。在分布式系统中，您将需要使用 UoW 之类的东西来为系统提供最终一致性。

【讨论】：

+1 我同意。我的猜测是，作者可能试图引导用户远离使用工作单元模式来保持与一切事物的一致性，这是程序员在我们对工具感到兴奋时容易陷入的陷阱类型。我认为他只是试图引导用户尽可能使用聚合来保持一致性。
在他关于聚合设计的论文中，Vernon 提到 UoW 作为管理事务一致性的方法之一（dddcommunity.org/library/vernon_2011 - 请参见第 4 页第 1 部分的脚注）。 “避免工作单元模式”对我来说似乎是一个奇怪的建议——对弗农方法的误解？
旧答案，但在聚合中非常有效地使用事务是在 CQRS+ES 实现中发布事件。例如，要达到最终一致性状态，不仅命令应该完成，而且事件应该通过使用的任何发布机制进行持久化。如果无法发布/调度事件，则无法实现一致性。即使没有 ES，它也不会显式伤害任何东西——只要它不用于跨越聚合边界，例如让单个命令更改多个聚合的过渡状态。
聚合以数据库为中心并定义了事务的范围，但是在现代分布式系统中，工作单元可以代表 ACID 操作：保存聚合、发送命令、发出事件。 IE。拥有 UoF 是必不可少的。
@SergeSemenov 聚合如何以数据库为中心而不是以域为中心？

【解决方案3】：

首先，聚合是一个对象，用于保存一组加载实体，以便应用一个命令。

“工作单元”基本上是动态聚合，允许对一组实体进行单个事务更新，而无需在代码中明确定义聚合来执行此操作。

这是以没有明确的 Aggregate 类为代价来放置保护不变量的突变方法的。

票数最高的答案包含：

但我们经常会遇到一次需要更改多个聚合的情况。事务变得更大，它们涉及的不仅仅是系统的一部分，我们谈论的是最终一致性。在这种情况下，UoW 是一个很好的帮手。

这是荒谬的，因为根据定义，聚合是事务所需的一组内容。如果您发现您“需要来自两个不同聚合的实体”，那么实际上您需要的是“定义一个包含对所需实体的引用的附加聚合”。

【讨论】：