【问题标题】:CQRS implementation detailsCQRS 实施细节
【发布时间】:2017-12-14 01:26:15
【问题描述】:
我正在使用 CQRS 和 Event-Sourcing 实现微服务。
我见过不同的 CQRS 实现,它们非常复杂。
我所理解和实现的是我为读取(查询)和写入(命令)制作了两个模型,读取模型具有物化视图,写入模型使用数据库,现在每当发生更新时,写入模型更新数据库并生成事件,并将详细信息记录到读取模型已订阅的事件存储中,读取模型通过读取事件来更新其物化视图。
我的问题是这个模型是否依赖于 CQRS 和 Event Sourcing 的基础?
【问题讨论】:
标签:
domain-driven-design
cqrs
event-sourcing
【解决方案1】:
听起来您已经实现了 CQRS,但没有实现事件溯源。
CQRS 意味着将写入端(命令)与读取端(查询)隔离开来,这听起来就像你正在做的那样。
但是,听起来您的事件只是从写入端到读取端的一种通信方式,而即使是源事件也是事实的来源。使用事件源实现的写入端只会保留事件(以及可选的快照),但在对数据库进行其他一些更新后不会这样做。写入端的数据模型将仅由事件日志(以及可选的快照)组成。
【解决方案2】:
写入模型更新数据库并生成事件,并将详细信息记录到事件存储中
这听起来不太对劲。写入模型不会更新数据库和事件存储,它会更新是事件存储的数据库。
CQRS 的核心思想是处理命令和处理查询可以使用不同的数据模型。如果可以接受一点延迟,那么我们将更改写入一个数据模型,然后在后台更新第二个数据模型以匹配第一个数据模型。除此之外,这允许我们选择适合目的的数据存储 - 如果我们需要支持一堆图查询,那么我们可以使用图数据库作为读取模型的一部分。
当我们将事件溯源添加到组合中时,上述模式不会改变。改变的是我们复制到写入存储中的状态表示从当前状态的快照变为历史的快照。所以我们适合写入模型的数据存储是一个事件存储。
事件存储取代快照数据库作为事实来源。