考える場所

ココロとカラダ、思考する全部

CQRSの小さな演習(3) ドメインイベント

データ更新を伴う業務の出来事に関する処理と、レポートするための画面表示に関する処理を同じに書こうとすればそのアプリケーションを複雑にしてしまいます。複雑であるとは、ふたつ以上の関心事が同じ所にあるということです。Webアプリケーションではリクエストがあってレスポンスを返すのですが、そこで一緒に更新処理もするし画面表示もするのは大変なことです。更新処理をして、画面表示をする、というようにするのがよさそうです。

It is not possible to create an optimal solution for searching, reporting, and processing transactions utilizing a single model.
- CQRS Documents by Greg Young

Greg Youngさんはひとつのモデルで検索やレポーティング、トランザクション処理をすることはできないと言っていて、CQRSではコマンドとクエリの責務を分離します。データベースからデータを取り寄せてごちゃごちゃっと更新してからごちゃごちゃっと画面表示に使う、というようなことをしないわけです。コマンドとクエリに対してそれぞれのモデルを設計します。

イベントとコマンド

今回、TODOリストを題材にしてみます。やりたいことが難しくないのでコマンドとクエリを分けるほどでもないような気もしますが、それでもモデルがすっきりして見通しがよくなるように思います。さて、まずはコマンド側について考えてみましょう。

TODOについて、どのような出来事が起こるかを考えます。今回は「追加した」「修正した」「やった」という出来事があるものとします。これらをイベントとしてモデリングします。それぞれAdded Fixed Didと名づけました。過去形にしています。

f:id:fukuchiharuki:20160305175906p:plain

イベントはいつ何をといった属性値をもつだけのオブジェクトです。何があったという出来事を表現します。たとえばDidは次のようにしています。

class Did {
  private Id id; // 何を
  private DoneAt doneAt; // いつやった
}

次に、TODOをどのようにするか(命令)を考えます。その先で出来事が起こることを考えて「追加する」「修正する」「やる」という命令があるものとします。これらをコマンドとしてモデリングします。イベントと1対1になっていますね。やりたいことが難しくなければコマンドはそのままイベントと対応づきます。それぞれAdd Fix Doと現在形で名づけました。

f:id:fukuchiharuki:20160305181729p:plain

コマンドもやはりイベントと同じで属性値をもつだけのオブジェクトです。何をするという命令を表現します。たとえばDoは次のようにしています。

class Do {
  private Id id; // 何をやる
}

コマンドからイベントへ

命令があって出来事が実際に起こるまでにはそのドメインの構造やルールが存在します。コマンドがあったからといって必ずしもイベントが発生するのではないわけです。

f:id:fukuchiharuki:20160319110057p:plain

次回は、

コマンドからイベントへ繋がるところのモデリングを考えてみます。

blog.fukuchiharuki.me

最初

blog.fukuchiharuki.me