<< リレーションシップ駆動要件分析(RDRA)の実践 | main | event とメッセージング 【きっと、良いパターン】 >>

state ソーシング、 event ソーシング 【スタイルの選択肢】

業務の情報の扱い方の基本スタイルとして、

* state ソーシング
* event ソーシング

がある。

state が先か、event が先か、という正反対のスタイル。

state ソーシング


現在の「状態」を中心にしたスタイル。

state オンリー


一番、単純なパターン。
いわゆる「上書き」モード。

メモリ上のオブジェクトを、 setter とか update メソッドで、最新の状態を保持する。
更新前の状態は、どこにも残っていない。

テーブルであれば、update 文で、最新の状態に上書きしていくパターン。

もっとも単純だし、これで要件が満たせるなら、これで必要十分。

情報源は、「上書き」された最新の state だけ。 これが、state ソーシング のもっとも、単純な state オンリー パターン。

state - audit log パターン


state を変更した時に、記録を残すパターン。
audit log ( 監査ログ ) 。

業務アプリでは、金銭がからんだり、責任の所在を明確にするために、この要求は多い。

実装方法としては、 state オブジェクトを更新した時に、いっしょに、audit log を書くパターン。
データベースだと、state テーブルを update するたびに、トリガーで、audit log を自動的に記録する。

情報源は、 state で、そこから、 audit log を派生させるパターン。

state - history パターン


状態・履歴パターン。

audit log と基本は、いっしょ。
異なるのは、audit log は、アプリケーションの通常の機能では、アクセスしない。あくまでも、監査目的の情報。

それに対して、 history ( 履歴 ) は、アプリケーションで、その情報を利用することを目的としている。

大きな違いは、「history (履歴)」の、識別キー を使った参照が必要になること。

例えば、バージョン番号とか、人が、業務上、意識する、なんらかの識別キーが表にでてくるのが、 state - history パターン。

実装の仕組みとしては、 state - audit log パターンといっしょ。
state を更新して、 history ( 履歴 ) を派生させる。

ここまでは、情報の起点が、更新可能な state オブジェクトまたは、state テーブル。

state ソーシングのバリエーション。

event ソーシング


状態の変化を、イベント(事象)として表現するパターン。
state ソーシングでは、すべての情報源は、最新の状態(state ) に更新するところから派生させる。

event ソーシングでは、event が、起点になって、現在の状態 ( state ) を派生させる。

テーブルで考えるとわかりやすい。

event レコードテーブルの、 insert トリガーで、 state テーブルを更新する、というパターン。
例えば、入庫イベントを記録したら、現在の在庫数を更新する。

紙ベースの業務では、event ソーシングのほうが、自然なパターン。
まず、入庫という経済イベントが起きたら、伝票を作成(起票)する。それから、元帳に 記帳 して、残高を変更する。

これを、すなおに、実装すれば、 event ソーシングスタイルになる。

紙ベースだと、 event ソーシングがあたりまえなのに、電子化(データベース化)すると、state ソーシング が、けっこう幅を利かせている。

これ、電子化だから、ではなく、IT技術者が、業務をよく理解していないから、そうなっているように思う。

紙だろうが、電子だろうが、 業務は、個別の事象を、まず、 起票 して記録し、合算や残高の変更は、伝票から派生させるのが、基本。

理論的には、イベントの記録だけあれば、現在高は、導出可能。
もちろん、それでは、残高参照に時間がかかってしょうがないので、「現在高」も、ついでに更新しておく。

情報源は、イベント記録で、現在の状態 (state)は、導出された値。

state オブジェクト/テーブルは、キャッシュや、インデックスみたいな、高速化の技法で、あって、本質的なオブジェクトではない、ということ。

event ソーシングで行ってみよう


始まったばかりの採用支援プロジェクトでは、この event ソーシングスタイルに、こだわってみようと思っている。

応募イベントを起点にして、採用可否の決定までの業務のサポートを、

「採用プロセスで発生するイベント」を情報源(ソース)として、「選考状況 ( state ) 」を導出しておく、というパターン。

選考状況の変更を、関係者に通知する、という業務ニーズがいろいろあるんだけど、これも、「イベント」を通知(メッセージング)するスタイルで、モデリングし、設計・実装しようと思っている。

業務のモデルとして、それが自然だと思っている。
また、Mule ESB というメッセージングのフレームワークが、なかなか、いい感じで使えそうとう、実装技術面からのサポートもある。

自分も今までは、event ソーシングぽいことを、なんとなくやってきたけど、初期のモデリング段階から、event ソーシングを明確に意識して取り組むのは今回が初めて。

さて、どんなことになりますか。

<参考>
マーチン・ファウラーの PoEAA の続編 wiki の

Event Sourcing パターン

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< May 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