在域驱动设计中避免工作单元模式

Question

我看过这个,这让我三思而后行......:

"避免工作单元模式.聚合根应该定义事务边界."

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

Answer 1

(我的文章之前,我建议阅读本章由五农"实施领域驱动设计"的书.它可以帮助聚集亲近,并包含在你的问题很长的答案.)

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

但是,我们经常遇到需要一次更改多个聚合的情况.交易变得更大,它们触及系统的一部分,我们谈论最终的一致性.在这种情况下,UoW是一个好帮手.

正如在上下文中提到的那样,很难猜出作者在想什么,但我想他讲述了交易一致性案例.在分布式系统中,您需要使用UoW之类的东西来为系统提供最终的一致性.

在他关于聚合设计的论文中,Vernon提到UoW是管理事务一致性的方法之一(http://dddcommunity.org/library/vernon_2011-见第4页第1部分的脚注).*"避免单位工作模式"*对我来说似乎是一个奇怪的建议 - 对弗农方法的误解？ (2认同)
@SergeSemenov 聚合如何以数据库为中心而不是以域为中心？ (2认同)

Answer 2

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

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

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

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

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