如何证明 DDD 中聚合的一致性（技术上）？答案

【问题标题】：How to prove the consistency of aggregates in DDD (Technically)?如何证明 DDD 中聚合的一致性（技术上）？
【发布时间】：2018-03-06 19:16:58
【问题描述】：

在使用 DDD 开发 Web 应用程序时，确保聚合的一致性非常重要。

我过去在一个 Web 应用程序（没有 DDD）上工作，我们尝试使用 Transactions 确保数据的一致性。所以，我们使用了 Serializable 事务级别，这对我们的团队来说是一场噩梦，因为我们的应用程序的性能太糟糕了，我们的用户报告了很多死锁问题。

现在我正在开发一个实现 DDD 原则的 Web 应用程序，我需要确保我们的聚合的一致性。

我在这里读到http://geekswithblogs.net/Optikal/archive/2013/04/07/152643.aspx，乐观并发/锁定是实现抛出分配版本或时间戳到我们的聚合以检查它的方法之一。

我的第一个问题是如何使用 C# 和实体框架结合 Sql Server 实现乐观并发，包括从头到尾的整个过程，以及如果我们以订单和行项目为例，该列/标志存储在哪里埃里克·埃文斯 (Eric Evans) 在他的书中给出了吗？

我的第二个问题是在竞争条件下确保聚合一致性的常用策略是什么？

我将不胜感激任何代码 sn-p 或参考。

【问题讨论】：

我最近一直在为同样的问题进行概念设计。我计划有一个全局版本计数器，它会在每次数据库写入时递增。并且还向所有表添加版本列，该列在行创建/修改时记录当前版本计数器。对行的每次修改都必须指定要修改的行的版本，并在版本不匹配时使事务失败。
@XiaoguoGe 在乐观锁定中你不使用事务
你仍然可以使用翻译但没有锁定。

【解决方案1】：

我的第一个问题是如何使用 C# 和实体框架结合 Sql Server 实现乐观并发，包括从头到尾的整个过程，以及如果我们以订单和行项目为例，该列/标志存储在哪里埃里克·埃文斯 (Eric Evans) 在他的书中给出了吗？

如果您使用单个表来存储整个聚合，那么您可以使用乐观锁定。例如，您可以使用JSON column to store 行项目。对于这种情况，文档库 NoSQL 数据库非常适合。

如果您使用多个表（即一张表用于订单，一张表用于订单项），那么我看不出您如何可靠地使用乐观锁定来确保原子性。在这种情况下，您需要交易。

我的第二个问题是在竞争条件下确保聚合一致性的常用策略是什么？

你只是retry the command。如果您将聚合设计为无副作用（至少不进行任何 IO 调用），那么这应该不是问题。

【讨论】：

但如果多个表使用 Serializable 事务级别，那就是一场噩梦。为此，您认为我应该使用什么最佳事务级别来防止死锁和防止更新过时的聚合。
@SimpleCode 如果你有一个丰富的域我建议将架构更改为 CQRS 和事件源
@ConstantinGalbenu 据我所知，一个表上带有乐观锁定的 READ COMMITTED 事务应该足以检测并发冲突，即使 AR 的数据分散在多个表中。 UPDLOCK 将在事务的整个持续时间内保持，因此版本检查将跨事务工作。
@plalx 我会赞成你的评论。我认为这将与更少的努力保持完美的工作，因为在我的情况下，我不需要实现 CQRS/ES，因为这种复杂性是不合理的我的项目。
@plalx 你是对的，但是乐观锁定不是悲观锁定（doh！）； “问题是如何使用 C# 和实体框架实现乐观并发” - 如果使用事务（在任何级别），那么它不是乐观锁定；