BLO:ArcBlock 课堂 ⑦ | Intro to CQRS and Commanded（全程视频 + 文字）_VEN

昨天上午8:00，ArcBlockTechnicalLearningSeries第六期“IntrotoCQRSandCommanded”,由ArcBlock后端工程师周蕾讲授。

#讲座全程视频

#讲座全程文字：浅谈查询职责分离(CQRS)模式

最近几年，在DDD的领域，我们经常会看到CQRS架构的概念,CQRS是查询职责分离模式(CommandQueryResponsibilitySegregation)的缩写。正好这些日子Arcblock的后端的服务有考虑使用CQRS的架构，所以今天和大家一起分享一下最近的研读收获。今天会从EventSourcing出发介绍CQRS，以及通过Commanded，一起看一看如何遵循ES/CQRS的概念开发应用程序。

什么是EventSourcing(事件溯源)？

EventSourcing本质来说是保存了发生事件的本身，而不是当前的事物的状态。在EventSourcing的概念里，Event作为既定的发生之后的事情，也是最小的单位。比如：

EventSourcing的工作模式：在下面这条数据流里面，由4个发生的事件(event)组成，进而每一次改变当前的状态，同时事件们的相对顺序也是我们需要保证的。

我们会得到这样的总结：

Sn=apply(Sn-1,En)或者Sn=reduce(E,S0,apply)

其中:(S:state,E:Event)

现在我们可以发现EventSourcing的优点：

每个状态发生的改变都有完备的日志记录，可追溯

优化了的写的操作，提高了性能

我们身边的EventSourcing

每个程序员的每天都离不开的Github。在Git的世界里，Events(事件)是Commits,State(状态)是文件系统。

WAL:也就是Write-aheadlogging,在数据写入到数据库之前，先写入到日志,再将日志记录变更到存储器中。Events(事件)是每一个操作,State(状态)是数据库。

对于EventSourcing来说，想做查询(query)怎么办？

试想一下，在一个银行系统里面，如果我们想要查询账户余额在1000块以上的用户，那我们难道需要把每个账户的按照Sn=reduce(E,S0,apply)这个公式在重新计算一遍吗？如果我们考虑用一个DB来保存Event，再用另外一个DB去专门为Query提供数据，同时两个DB通过发送消息进行信息同步，如何？CQRS某种程度上就解决了这样的问题。

CQRS是什么？

CQRS全称是CommandQueryRsponsibilitySegregation，将应用程序分为两部分：命令端(Command)和查询端(Query)。命令端处理程序创建，更新和删除请求，并在数据更改时发出事件。查询端通过执行查询来处理查询，并且通过订阅数据更改时发出的事件流而保持最新。CQRS使用分离的接口将数据查询操作(Queries)和数据修改操作(Commands)分离开来，这也意味着在查询和更新过程中使用的数据模型也是不一样的。这样读和写逻辑就隔离开来了。

CQRS里面的一些概念：

Command(命令):不返回任何结果，被校验成功后但会改变对象的状态。

Query(查询):有返回结果，但是不会改变对象的状态。

Aggregate(聚合):保存状态,处理command，和改变状态。

EventStore:存储Events。

怎么遵循CQRS模式建立应用程序?

首先我们会基于一个Commanded,一个Elixir遵循CQRS/ES模式实现Commandside的库。

1.Commands

Commands是用户发送给应用程序的指令，表示用户的一种请求，当然请求是有可能失败的，如果想在余额有10的账户里面取出1000块这样的操作。每一个指令对应是一个module，然后使用defstruct定义域，命名方式是MineCoin，动名结构。

defmoduleMineCoindo

defstruct[

:account_id,

:nonce

]

end

2.Events

Events是由Command产生，最终导致状态改变。会最终在eventstore里面序列化存储，可以用于日后想要恢复状态。命名方式相比于Command来说发生了变化，CoinMined，过去式表达一种过去发生的事实。

defmoduleCoinMineddo

defstruct[

:account_id,

:nonce

]

end

3.Aggregates

Aggregates作为接受处理Command，产生或者引起对应事件的发生，以及一些改变状态的处理器。

里面包含两个函数：execute方法使用来添加我们的校验Command的一些逻辑，输入时状态和command，如果成功输出就是Event。apply函数用来更改状态，注意这里的对象是已经是生成出来的event。

|{:error,term(。

@specapply(state,event)::state

现在我们有了Command,Event,Aggregates...

那我们还需要一个派遣的角色帮助我们把Command走向对应的Aggregates。Commanded库提供了Router：

defmoduleCoins.Routerdo

useCommanded.Commands.Router

aliasCoins.Account

aliasCoins.Commands,as:C

dispatch(

[

C.MineCoin

to:Account

)

end

最后我们使用Commanded推荐的EventStore，它是基于PostgreSQL作为存储引擎,来保存Events。

现在我们可以说是齐活了，可以发现我们构建了如下的整个流程：这样我们就可以愉快发布Commands和生成对应的Events。

最后怎么进行数据同步到读取的DB里呢？

在这里Commaned库推荐了CommandedEctoprojections来做Eventhandler，或者也可以采用Kafka同步信息，在这里就基于不同的应用场景选择适合的Eventhandler。

主讲

周蕾

ArcBlock后端工程师

●美国东北大学毕业

●信息系统计算机专业硕士

●区块链技术爱好者

●编程语言：ElixirJavaScriptPython

下周三上午8:00，同一时间，ArcBlock区块链技术培训系列讲座第7期，现在开放报名！

点击文末左下角“阅读原文”登陆注册：

https://hack.arcblock.io/learning/

或登陆掘金注册：

https://juejin.im/events/all

ArcBlock课堂①|IntrotoGraphQLandAbsinthe

ArcBlock课堂②|IntrotoEthereumSmartContract

ArcBlock课堂③|IntrotoAWSDataPipelineServices

ArcBlock课堂④|IntrotoAWSAthena

ArcBlock课堂⑤|WhatisAWSKinesis

ArcBlock课堂⑥|多步验证那些事

ArcBlock课堂预告|是的，我们将开放大部分技术讲座

区块博客

BLO:ArcBlock 课堂 ⑦ | Intro to CQRS and Commanded（全程视频 + 文字）_VEN

区块博客