DDD:决定何时倾向于最终的事务一致性

Question

我正在阅读Vaughn关于有效集料设计的系列文章。

关于在事务性还是最终一致性之间作出决定的问题，它说明如下：

与埃里克·埃文斯讨论这一点，揭示了一个非常简单和合理的指导原则。在检查用例(或故事)时，询问是否是用户执行用例以使数据一致的工作。如果是的话，试着让它在事务上保持一致，但必须遵守其他的集合规则。如果它是另一个用户的任务，或者是系统的任务，那么允许它最终保持一致。这一点的智慧不仅提供了一个方便的打破平局，它帮助我们获得一个更深刻的了解我们的领域。它公开了真实的系统不变量:必须保持事务一致的不变量。这种理解比拖欠技术知识要有价值得多。

这个建议使我感到困惑。我在职业生涯中编写的大部分软件对最终用户都是有用的，因为它免除了他们保持数据一致性的责任。因此，用户希望随时都能观察到一致的状态，而不会延迟。对于为实现一致性的软件付费的客户来说，所观察到的每一个不一致的状态都是一个错误。

根据我的经验，在提交请求时，用户通常宁愿稍等片刻并观察到一致的状态，也不愿拥有稍后更改以保持一致性的即时答案。

相反，当实现一致性是用户的责任时，我们的系统会警告他不一致，但允许他最终通过执行几条较小的命令来实现一致性，而不是要求用户使用一个巨大的命令来实现一致性。

为什么埃文斯和弗农建议最终的一致性，当系统的工作是获得一致性正确和事务一致性的时候，它是用户的责任？

你能指出例子约束和用例，其中交易或最终的一致性被认为适合根据上述规则？

Answer 1

看来你想得太多了。这个建议在几个不同和相关的用例中得到了说明。

1.用户提交建议:用户负责确保提案一致的用例。换句话说，它被认为是用户的责任，导致一致的结果数据突变。

(A)用户定义建议书并将其提交给系统的建议书上下文

(B)该制度以交易方式维持新建议。

(C)用户立即看到提案已得到成功界定

2.检查订阅计划的过度使用:用例从#1一直持续到最后的一致性。系统负责确保用户的订阅计划不超过分配的建议书数量。

(D)在最近提交的提案中，提案发出了ProposalSubmitted事件，该事件与提案一起在事务上持续存在

(E) ProposalSubmitted由消息处理程序在用户帐户上下文中发布并随后接收。

(F)帐户上下文增加计数用户建议，记录值，如果达到建议限制，则发出AccountLimitReached { type=Proposal }

(G)建议上下文中的消息处理程序发布并随后接收AccountLimitReached

(H)建议书帐户记录已达到用户限额

(I) AccountLimitReached也由通知上下文和电子邮件/SMS/.发送给用户，以通知帐户过度使用和要采取的操作。

3.建议书定义-计数器付费墙:在记录了提案帐户限制的情况下，用户有机会进行升级，并这样做。在这种情况下，用户会在两个不同的有界上下文中进行修改。虽然最终是一致的，但用户并没有意识到这一点，并且对多聚合持久性负责。

(A)用户选择定义新提案的选项

(B)系统报告用户的计划限制已经达到，并提供升级选项

(C)用户单击升级选项并看到旋转繁忙的图标。

(D)升级记录在发布事件AccountLimitIncreased的用户帐户上下文中

(E)用户最初提出的定义新提案的请求现在得到了满足(没有进一步的用户手势)

4.用户提交数字签名自验证方案:用户负责使两个集合事务一致的用例。

(A)用户定义建议书，选择电子核查和签字选项，并将其提交给系统的建议书上下文

(B)系统通过用户的安全用户令牌对用户进行验证，并请求新的数字签名对象。

(C)该系统以交易方式维持该建议及新的数码签署。

(D)用户立即看到提案已被成功定义，并附有数字签名。

沃恩

银行不会在一笔交易中使账户转账保持一致

Answer 2

关于微型服务有一个不可否认的基本原则。microservices是独立的实体；如果您正在构建一个基于微服务的系统，那么根据定义，您就不能让它们依赖于中央数据权威(如关系数据库)，因为您的微服务将不再是独立的。为每个微服务提供自己的独立数据存储意味着您必须满足于最终的一致性。

当然，不必是那样的。当然，您可以将所有“微服务”绑定到中央数据存储，并在任何地方获得事务一致性；Actor模型总是这样做的。我只是不知道纯粹主义者会称其为微服务架构。

我认为Vernon Vaugn的观点是，用户通常不负责实现一致性；系统是。一致性是一种非功能性的需求；它不采用“作为用户，我想要执行某些动作以便我可以实现某一目标”的形式。

尽管如此，用户确实认为一些交互(比如将钱从一个支票账户转移到另一个账户)在事务上是一致的，而不是最终一致的。你不想让一个银行客户问“我的钱去哪了”，结果几个小时后它就出现在了目标账户中。

Answer 3

这个建议使我感到困惑。

不是你的错。

我怀疑他试图表达类似于何时避免CQRS中Udi Dahan的想法；这是协作用例和非协作用例之间的区别。

考虑一个支票登记册；一个分类账，描述每个可转让票据从一个账户中提取。每个条目通常包括支票的唯一标识符(它所针对的帐户通常是隐式的--每个寄存器与单个帐户相关联)、备注字段、金额和运行余额。

运行余额来自支票本身的详细信息，以及登记册中先前的余额项(状态)。通常不会有来自其他人的令人惊讶的条目，或者同时尝试记录几张支票的拥堵现象。因此，合理地断言一个不变量，即运行余额应该与条目的累计总数相匹配。

另一方面，要使登记册余额与帐户余额相匹配要复杂得多--账户余额将取决于其他合作者存入支票、转移资金、贷记账户。因此，试图将寄存器中运行的总数与帐户总数对账的工作可以(而且应该)推迟到以后。