ドメイン上のアクティビティから分析する
ドメイン上のアクティビティは、大別して以下の3つがある。
- コマンド
- イベント
- クエリ
私はドメインを分析する際はイベントを入り口にして3つを行ったり来たりすることが多い。お気づきかもしれないが、分析結果をそのままCQRS/Event Sourcingに適用できる。
では、それぞれどういう特徴があるか、以下に簡単にまとめる。
コマンド
コマンドは、アクションを実行するためのリクエストを意味する。コマンドはリクエストであるため、まだ何かが起こったことを説明するものではない。また、リクエストは拒否される可能性がある。
コマンドは特定の宛先に送られることが多い。コマンドが受理されるとドメイン状態が変化する。コマンド前の状態には戻れない。例えば、「ショッピングカートに商品を追加する」コマンドが受理されると、カートに商品とその数量が追加されて、カート状態が更新される。ただし、事前に設定した予算額をカートの合計金額が超えるなら、そのコマンドはビジネスルールに基づいて拒否されるかもしれない。
イベント
イベントは、ドメイン内で過去に起こった出来事を意味する。コマンドの現在形に対して、動詞の過去形で表現される。また、それはコマンドの結果であることが多い。たとえば、AddCartItemコマンドが受理されるとドメイン状態が変更され、CartItemAddedイベントが発生する、などが考えられる。
イベントは過去に起こったことなので、そもそも否定はできない。否定すると歴史の改ざんになる。イベントの利用する/しないの選択は可能だが、イベント自体の否定はできない。イベントの多くは、多くのサブスクライバにブロードキャストされる。異なるマイクロサービスに送られることが多い。コマンドがドメイン状態の変更を引き起こすのに対して、イベントはドメイン状態の変更を記録する。
イベントを見分ける方法
T字形ER データベース設計技法にはイベントを見分ける方法が示されている。
エンティティ名に「する」を付加した際に、意味が通じるものがイベントに該当する。
- 受注する(Event)
- 請求する(Event)
しかし、例外もある。IDと分類名称しか持たない分類エンティティは、この方法では”分類する”となり一見イベントだが、実際はリソースである。
- 分類する(?)
詳細な定義では、タイムスタンプを保持するか、監査証跡を保持するかの、どちらかに該当すれば、イベントと判断する。
イベントに関連するリソースとエージェント
イベント以外のエンティティをリソース(モノ)という。
REAモデルでは、リソース(モノ)とエージェント(ヒト)がイベントに関連付くとされている。イベントを列挙すれば、ドメイン分析の基点にできる。
- 受注イベント
- 受注日
- 受注先顧客ID(エージェント)
- 受注商品ID(リソース)
- 数量
Event Stromingはイベントを中心に分析する
イベントをヒントにして、ドメインの活動を分析することができる。Event Stormingはそれを体系化した分析手法である。そして、コマンドとイベントに関連する集約を抽出することができる。
クエリ
クエリはドメイン情報を得るためのリクエストを意味し、常にレスポンスを期待する。ドメイン情報はクライアントのために非正規化されたデータが使われることが多い。確認応答ではなく、クエリに応じた詳細な情報を返す必要がある。クエリはドメイン状態を変更してはならない。
最終的に集約・リードモデル・ポリシーを洗い出す
上記の3つの要素を洗い出して何がうれしいのか。それは最終的に集約(ドメインモデル)・リードモデル・ポリシー[1]を洗い出せること。下図はそれらを洗い出すデザインレベルのEvent Stormingのモデル図。ちなみに、実装基盤であるリアクティブ・アーキテクチャではこれらのモデルはメッセージとして扱うが、分析段階からそういう解釈をしたほうがわかりやすいかもしれない。
-
ポリシーは、イベントをきっかけにコマンドが発火する条件のこと。 ↩︎
Discussion