transactions - 命令处理程序和执行的事务边界是什么？

Question

让我们以一个用于编辑客户信息的 UI 示例为例。用户编辑 5 个字段并按下“提交”。因为我们是优秀的抽象主义者，所以我们对 5 个字段进行了编辑，并使它们成为不同的命令（描述对特定字段的编辑）。

命令处理程序最终会在使用 NHibernate 等工具持久化的对象上设置属性，因此我们最终会对数据库执行 UPDATE。

我的主要问题是：从数据库性能的角度来看，发出单个 UPDATE 语句更有意义还是发出 5 个不同的 UPDATE 语句更有意义？

我喜欢命令处理程序作为事务边界的想法。要么它工作并且事务被提交，要么它不工作并且事务被回滚（我们可能重新排队再试一次）。每个命令的成功或失败相互独立。

另一种方法可能是将这些命令的处理包装到单个数据库事务中，这样当 NHibernate 决定刷新时，它最终会发送单个 UPDATE。但这使得命令的处理成为一种全有或全无的交易，我不一定能异步执行它们。

但是，如果我想确保所有命令都正确执行，并在失败的情况下完全回滚？也许有一个包含许多较小事务的分布式事务？这可能导致数据库争用，增加死锁的风险，从而减慢处理速度（进一步增加死锁的风险）。但与此同时，一致性是关键。我想这是可用性和一致性之间的权衡（参见 CAP）。

Answer 1

从数据库的角度来看，发布一次更新几乎总是更好 - 但它是否真的重要取决于上下文。

但是，我不确定作为“优秀的抽象主义者”，您是否真的想在编辑 5 个字段时发出 5 个命令。您在 DDD 中真正想做的是为用户通过 UI 执行的每个逻辑操作发出一个命令。通常每个操作只有一个，尽管对于更复杂的场景可能不止一个。举个简单的例子，如果有人正在更新他们的地址，您没有每个字段都有一个命令 - 您有一个用于更新地址的命令。

您拥有的最低粒度级别将是命令，因此命令处理程序中的任何内容都需要包装在事务中。我们所做的是将命令放入一个工作单元中，因此当我们发出多个命令时，它们要么全部通过，要么全部失败。最后，我们提交事务，这意味着任何更改的对象（对我们来说是聚合根加上我们正在使用事件源的事件）都会被持久化。如果您使用 NHibernate 来执行此操作，它可能会执行一次操作 - 尽管这当然取决于您在持久性方面所做的事情。