聚合是否涉及数据库中的读锁?

时间:2015-10-08 07:34:36

标签: concurrency domain-driven-design aggregate

我读了Eric Evan关于 DDD 的书,聚合一章。

在处理Order / OrderLine示例时,声明:

  

当两个用户都保存了更改时,订单将存储在   违反域模型不变量的数据库。一个重要的   商业规则已被打破。甚至没有人知道。显然,锁定   单个项目不是一个充分的保障措施。 相反,如果我们锁定了   一次整个订单,问题本来就会被阻止。

我很清楚Aggregate的本质是用单个包装的数据库事务来保护不变量。

但是,如果每个聚合都指定在数据库端具有读锁,以防止潜在的并发问题(竞争条件),同时由多个用户同时修改此聚合?

聚合的真正意义 是否为数据库端的读锁收集了一些元素?

对此的任何澄清都会让我感到高兴。

2 个答案:

答案 0 :(得分:7)

不,两者是正交的:

聚合设计的目标是建立一致性边界并保护该边界内的不变量。锁定设计的目标是在应用程序中启用适当的并发级别。

这意味着使用相同的聚合设计,不同的锁定机制可能有意义(取决于应用程序的非功能性要求)。

答案 1 :(得分:3)

  

我很清楚Aggregate的本质是保护不变量   使用单个包装的数据库事务。

是吗?聚合根作为围绕其自身不变量的一致性边界存在。鉴于持久性在一个完全不同的过程中在网络中发生,过程中的聚合如何能够保证在其控制之外的某些事物之间保持一致性?

DDD的本质是区域和基础设施问题的分离;聚合应该根据建模(订单,产品,客户),其他一切(数据库,持久性,锁定,交易)是基础设施,不应该污染你的域名模型。