我正在玩DDD＆amp; CQRS，我向前推进了遗留申请。
假设我有一个文章实体，我可以投票。
当投票在一篇文章上投票时，我想根据投票的价值增加或减少一个计数器。
这个计数器是我的查询模型的一部分，因此我认为它不适合域模型，由于这些原因，我决定编写一个CastArticleVoteService，在其中我将业务逻辑放在投票上，然后我发送一个事件由自定义事件处理程序处理，后者依次更新数据库中的计数器。
首先，我对此持怀疑态度，因为我告诉自己“嘿，更新计数器的过程应该与保持数据的过程处于同一交易中”。但如果我有多语言持久性（即：MySQL / Redis），这显然是错误的。
但是，事务仍然适用，我怎么能确定整个事件处理程序是否正确处理并且我的数据是否一致？ （这是我的柜台）。 （那么异步事件处理程序呢？）
任何提示？
答案 0 :(得分：4)
好的，这是我对你问题的看法：
event driven＆amp; CRQS架构，使用event sourcing作为模式也很常见。
这意味着您的投票不会存储为计数器（state），而是存储为向上/向下投票（fact）。
在您的场景中，要查询文章累积的投票数，您可以阅读与聚合相关的所有事件，并按照它们发生的顺序逐个（在内存中）应用它们并获得最终状态聚合实例（article）。
有时，当事件量很大时，会将最新事实保存在最近的事实中，以便将这些事件应用于聚合。
值得注意：在应用事件时要小心副作用 获得国家。因为如果投票上/下事件导致了一篇文章 例如关闭并发送电子邮件给作者，然后你没有 希望在重播这些事件时再次发送该电子邮件。
将此视为银行借记/贷记事件的财务等价物。银行不仅存储您的余额。它们实际上存储了您的所有交易，然后进行对帐并更新余额。
如果债务人/债权人账户在同一银行内，某些交易会立即发生
此外，由于您拥有与系统进行的所有用户交互的数据流，因此您可以稍后以不同的方式使用该数据，以获得从设计系统开始时就没有想过的新功能（例如，Analytics）？ ）
进一步阅读：
答案 1 :(得分：2)
聚合定义事务边界。当您决定采用事件驱动的体系结构时，您决定最终的一致性。所以你只需要选择：交易或事件。
请注意，在大多数情况下，最终的一致性对于企业来说完全没问题。这只是开发者通过RDBMS在大学讲课/洗脑的交易迷信;）