我正在使用CQRS和Event-Sourcing实施微服务 . 我已经看到了CQRS的不同实现，这些实现非常复杂 .
我已经理解和实现的是我已经为Read（Query）和Write（Command）创建了两个模型，read模型有一个物化视图，而write模型使用了Database，现在每当发生更新时，write模型都会更新数据库并生成一个事件，并将详细信息记录到读取模型已订阅的事件存储中，并且读取模型通过读取事件来更新其物化视图 .
我的问题是这种模式是否依赖于CQRS和事件采购的基础？
写入模型更新数据库并生成事件，并将详细信息记录到事件存储中
这不会更新数据库和事件存储，它会更新作为事件存储的数据库 .
CQRS的核心思想是处理命令和处理查询可以使用不同的数据模型 . 如果可以接受一点延迟，那么我们将更改写入一个数据模型，然后在后台我们更新第二个数据模型以匹配第一个数据模型中的数据 . 除此之外，这允许我们选择适合目的的数据存储 - 如果我们需要支持一堆图形查询，那么我们可以使用图形数据库作为读取模型的一部分 .
当我们向混合添加事件源时，上述模式不会改变 . 改变的是，我们复制到写入存储的状态表示从当前状态的快照变为历史快照 . 因此，我们适合写模型的目的数据存储是一个事件存储 .
事件存储将快照数据库替换为事实来源 .
听起来你已经实施了CQRS而不是事件来源 . CQRS意味着将写入侧（命令）与读取侧（查询）分开，这听起来就像您正在做的那样 .
然而，听起来您的事件仅仅是从写入侧到读取侧的通信方式，而在即使采购事件中也是事实的来源 . 使用事件源实现的写入端只会持久保存事件（以及可选的快照），但在对数据库进行一些其他更新后不会这样做 . 写入侧的数据模型将仅由事件日志（以及可选的快照）组成 .
2 回答
这不会更新数据库和事件存储，它会更新作为事件存储的数据库 .
CQRS的核心思想是处理命令和处理查询可以使用不同的数据模型 . 如果可以接受一点延迟，那么我们将更改写入一个数据模型，然后在后台我们更新第二个数据模型以匹配第一个数据模型中的数据 . 除此之外，这允许我们选择适合目的的数据存储 - 如果我们需要支持一堆图形查询，那么我们可以使用图形数据库作为读取模型的一部分 .
当我们向混合添加事件源时，上述模式不会改变 . 改变的是，我们复制到写入存储的状态表示从当前状态的快照变为历史快照 . 因此，我们适合写模型的目的数据存储是一个事件存储 .
事件存储将快照数据库替换为事实来源 .
听起来你已经实施了CQRS而不是事件来源 . CQRS意味着将写入侧（命令）与读取侧（查询）分开，这听起来就像您正在做的那样 .
然而，听起来您的事件仅仅是从写入侧到读取侧的通信方式，而在即使采购事件中也是事实的来源 . 使用事件源实现的写入端只会持久保存事件（以及可选的快照），但在对数据库进行一些其他更新后不会这样做 . 写入侧的数据模型将仅由事件日志（以及可选的快照）组成 .