<< state ソーシング、 event ソーシング 【スタイルの選択肢】 | main | イベントソーシングスタイルを実装する >>

event とメッセージング 【きっと、良いパターン】

前の記事で、 state ソーシングスタイルと、event ソーシングスタイルについて書いた。

単純にいえば、メモリ上でオブジェクトを操作する順番、そして、データベース操作の順番の問題。

state ソーシング


state ( 現在の状態 ) オブジェクトの更新が最初。
必要が、あれば、audit ログ(監査記録)とか、history ( 履歴 ) オブジェクトを作成する。

テーブルであれば、state テーブルを update すると、トリガー で、監査テーブルにレコードを insert したり、history テーブルに insert する、というやり方。

顧客の連絡先、例えば、住所を変更したら、住所変更ログを書いたり、住所変更履歴を作成する、というパターン。

event ソーシング


ビジネスの事象オブジェクトを作成する。 そのオブジェクトが、しかるべき、state オブジェクトを変化させる。

入庫があったら、入庫イベントオブジェクトを作って、そのイベントオブジェクトを処理すると、「在庫」オブジェクトの現在高を更新。

入庫レコードを作成すると、トリガーで、在庫テーブルの「在庫数」を 自動更新。

書類選考の合格イベントを記録したら、「選考状況」オブジェクトのステータスを「書類選考合格」に更新する。

というような、パターン。

システム間の連係


今までの例は、ローカルなアプリケーションで、メモリ上のオブジェクトやデータベーステーブルでの操作の順序の話。

システム間の連係になると、event (変化が起きたこと)をメッセージング(通知)するのが基本パターン。

仕事探しのサイトで応募があったら、採用管理システムに通知。
採用管理システム側で、選考結果を変えたら、仕事探しサイトに通知して、さらに、メールで、応募者に通知。
...

人とシステムの連係であれば、何か、関心事に変化があったら、電子メールで通知する。
システム間であれば、変化があったら、メッセージを非同期で送る。(例えば、XML over HTTP で)

関心事に変化があったら、それを、イベントオブジェクトとして表現し、非同期メッセージングでしかるべきところに送る、というのが業務アプリの基本パターン。

event ソーシングパターンは、メッセージング(通知)という仕組みを使って、エンタープライズアプリケーション間を連係を実現する有力な手段。

event ソーシングスタイルは、

* メモリ上のオブジェクトの操作
* ローカルデータベースを使った永続化
* リモートシステムとの連係

に一貫して使える、基本パターン、ということ。

業務の基本、

* 起票 (イベントの表現 & 永続化)
* 記帳 (現在の状態の表現 )
* 連絡 (通知)

を、素直に、メモリ/DB/通信 で実装するには、 event ソーシングスタイルが、よさそう。

コマンド、イベント、ドキュメント


メッセージは、基本的に3種類ある。

コマンド・メッセージ


メッセージの主たる内容が、「指示」や「依頼」であるパターン。
リモート手続き呼び出しを、非同期にしたもの。

メソッド名と、そのパラメータセットを、そのままメッセージにする。

システム間の結合度はかなり強い。
非同期だけど、相手からの回答があることを、前提としている。
(少なくとも、こちらが指示した内容を、相手が実行することを期待している)

イベント・メッセージ


変化があったことだけを伝える方式。

どんな変化があったか、詳しく送る場合もあれば、「変化したよ」ということだけを通知する方法もある。

「変化したよ」だけの場合は、イベントメッセージを受け取った側が、必要だと判断すれば、詳細情報を、取りに行く。

イベント・メッセージの設計・実装で興味深いのは、

・イベントメッセージの送り先
・詳細情報の手に入れ方

を、送る側が意識しない、という設計ができる点。

イベントメッセージを、関係がありそうなところに、ブロードキャストすると、関心がある受信者だけが、それを処理し、また、必要な受信者だけが、必要な詳細情報を、自分で取りに行く、というパターン。

例えば、会社で、「お中元でビールをもらいました」というメッセージを社内のブロードキャストすると、ビール飲みたいやつが、しかるべき場所(冷蔵庫?)に、勝手に取りに行く、というやり方。

これは、システム間の結合を、劇的に「疎」にできるパターン。

というか、人が、ビジネスや社会活動をする時の基本パターンがこれ。

event ソーシングで、event メッセージング、というアーキテクチャスタイルが、これからのエンタープライズアプリケーション設計の基本パターンなんだと思う。

ドキュメント・メッセージ


メッセージの中身が「ドキュメント」、つまり、データだけのメッセージングのパターン。

これも、実際の業務では多いパターンですね。「書類送付」。
あるいは、システムでも、CSV ファイルを送る連係方式は、このドキュメントメッセージングのバリエーションですね。

ドキュメントメッセージは、「コマンド」つまり「指示」とか「依頼」は明示しない。
メソッド名なしに、パラメータセットだけ送る、という、ある意味、とても乱暴なやり方。

実際の業務では、多いパターン。

応募、注文のように、しかるべき「送り先」にドキュメントを送れば、しかるべき処理をしてもらえる、という了解の上になりたっている。

「送り先」がポイント。
あるいは、受け取った側が、ドキュメントの内容を判断して、処理をやり分ける、という仕組みも現実には多い。

アプリケーション間の結合度としては、「コマンド」と「イベント」の中間。

アプリケーション間である程度のデータ形式の合意が必要。
受け取った側が、自分の都合だけで、データ項目の取捨選択や解釈することが可能なので、コマンドメッセージングよりは、結合度が低い。

メッセージングの設計


「コマンド」「イベント」「ドキュメント」の選択。

コマンド・メッセージングの設計


これは、メソッドの設計そのもの。

メソッド名(コマンド名)、パラメータ形式、戻り値、例外、をそれぞれ設計する。

これを、アプリケーション間で合意するわけだから、結合度はかなり密になる。
変更が大変になるパターン。

イベント・メッセージングの設計


何を通知するか ( event タイプの列挙 )
誰に伝えるか ( 宛先、場合によっては、ブローカーの設計や、ブロードキャストの設計 )
どこまで伝えるか ( 詳細情報をメッセージに含めるか)

いろいろバリエーションがあって、なかなか興味深い、設計テーマ。

もちろん、答えは、「ドメイン」の言葉に耳を傾けること。
テクニカルな検討ではなく、「業務」でどうやっているかが、その答えになる。

ドキュメント・メッセージングの設計


乱暴にいえば、紙、画面のフォーム、csv ファイルなど既存の情報の表現を、XML 形式で表現すれば、設計完了。
通信方法は、HTTP という便利な仕組みがるので、XML 形式のデータ表現さえ設計すれば、 XML over HTTP で実装完了、というわけだ。

もちろん、XMLの組み立てとか、解釈とかの処理は必要だけど、最近は、O-X マッピングのフレームワークとかも、なかなか良い感じになってきたので、実装の負担はかなり減ってきている。

XML ドキュメントの 設計だけが課題、という感じ。

イベント+ドキュメントが基本


実際のアプリケーション設計は、

  • イベントメッセージングのための event タイプの設計
  • 詳細情報を伝えるためのドキュメントメッセージングの XML 形式の設計

の2つが、二大設計課題ということ。

ここがちゃんと設計できちゃえば、アプリケーションの骨格は、かなり固まるはず。

(ここまでは、仮説)
この仮説を、今回の、仕事探し+採用管理のシステムで、実践しながら、設計・実装ノウハウを獲得したいと思っている。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
1234567
891011121314
15161718192021
22232425262728
293031    
<< July 2018 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM