<< ドメインオブジェクトは 「固定」属性と「変動」属性を見分けるべし 【パターン】 | main | 「知りたいこと」を提供する 【パターン】 >>

「状態の変化」のモデリング

エンタープライズアプリケーションは、関心事オブジェクトの「状態の変化」を扱うための仕組み。

その枠組みを、絵にしてみた。

状態変化のフレームワーク

3層構造


全体の構造は、REST スタイル、 イベント駆動、 データ中心 の三つの情報の扱い方を3段に積み重ねている。

REST スタイル


REST スタイルは、関心事オブジェクト(=リソース)の、「現在の状態」を GET したり、「意図する状態」を PUT する、モデル。

「現在の住所」を GET してきて、「新しい住所」に書きなおしてから、それを、PUT する、ことで、「関心事オブジェクト」の状態を変化させるパターン。

「状態」は、リソースそのものの状態ではなく、XHTML とか、 XML とかの形式で「表現(represent ) 」したもの、というところが、ポイント。 

状態をある表現形式にして、「 転送 (transfer) 」するというスタイル。

イベント・メッセージング


真ん中は、イベント駆動アーキテクチャ (EDA) スタイル。
イベントのメッセージングが、基本モデル。

アプリケーションの外部で発生した、何らかの変化が「イベント」メッセージとして送られてくる。
変更イベントを受信したら、イベントの内容に応じて、関心事オブジェクトの状態を変化させる。

振り込みが発生したら、残高を更新する、というパターンですね。

関心事オブジェクトの状態を変更したので、今度は、アプリケーションの内部で、「変更イベント」が発生する。
必要に応じて、そのイベントを、外部へ、送信する必要がある。

残高が更新されたことを、口座の名義人に、メールで通知する、ときのパターン。

記録


データ中心(DOA)の主な関心事。

記録する対象としては、

1. イベント・メッセージの受信の記録
2. 関心事オブジェクトの(変更後の)現在の状態
3. 関心事オブジェクトの変更履歴(=過去の状態)
4. イベント・メッセージの送信の記録

がある。

REST スタイルと イベント・メッセージング


両方とも、現在の状態を変更する。

大きな違いは、

◎ REST では、「状態」全体を、転送しようとする。
◎ イベントは、「必要最小限」の情報だけを送受信する。

ということ。

REST では、XML などで、情報「全体」を表現する形式を、設計することになる。

イベント駆動では、伝えるべき「最小限」の情報は何か、という設計をする。

また、REST は、 PUT する側は、「変更」を明確に意図している。

一方、イベント駆動では、「イベント」を送る側が、受け取ったアプリケーション側で、何が起きるかは、知らない。 そもそも、受け取り側のアプリケーションが、誰であるか、どんな関心事オブジェクトを管理しているか、ということすら知らない可能性がある。

メッセージングサービスは、イベントメッセージの発信側は、 End to End の通信を想定していない。

後続のサービスに、イベントを送信したら、それが、どこの誰に届くかは、知らない。

REST も、比較的、疎結合のスタイルだけど、イベント・メッセージングは、もっと、疎結合の仕組み、ということ。

記録


現実のアプリケーションでは、すべてのケースを、記録するとは限らない。

もっとも単純なアプリケーションでは、データベースに「現在の状態」を上書きするだけ。
これだと、変更の履歴が一切ない。メッセージの受信や送信の記録も残さない。

さすがに、エンタープライズアプリケーションだと、これではまずいことが多い。

基本的には、メッセージの受信送信の記録は残すべき。

ファウラーは、「 Domain Event 」パターン、それと関連する 「Event ソーシング」パターンで、面白いことを言っている。

だいたい、こんな感じのことを言っている:

>変更の動機となった、外部からの刺激(イベントメッセージ)だけを、
>永続化しておけば、十分かもしれない。
>つまり、「現在の状態」は、イベントの履歴から導出できるので、永続化の必要はない。

>もちろん、導出には時間がかかるので、
>「現在の状態」を、メモリ上に「キャッシュ」しておく。
>キャッシュのバックアップという意味で、データベースに書き込んでも良いが、
>アプリケーションの基本モデルとしては、
>「現在の状態は、永続化しない」という可能性がでてくる。

これ、なかなか興味深い議論。

状態の変化のフレームワーク


エンタープライズアプリケーションの中核課題である、関心事オブジェクトの「状態の変化」を扱うための仕組みとして、三層のモデルを提示してみた。

モデリングのためのツール


この枠組みは、ドメインの「モデリング」のパターンを考えるためのツールと考えている。

それぞれの要素(楕円)と、その間のアクション(矢印)を、具体的に、業務の関心事、やり方、ルールに当てはめながら、関心事オブジェクトの「状態の変化」を、具体的にモデリングするための手掛かり、として考えている。

例えば、関心事オブジェクトが、「銀行口座」であれば、

・「残高照会」は、REST の GET
・現金引き出し(の反映)は、 REST の PUT。
・外部からの振り込みは、 イベントで通知され
・振り込みで、残高が変わった場合、口座名義人にメールで入金通知がいく

そして(おそらく)すべての変化は、記録することになる。

関心事オブジェクトが、「本」の場合は? 「顧客」の場合は?、「to-do タスク」の場合は?

こういう例で、もう少し、具体的に、関心事オブジェクトの「状態の変化」のモデリングパターンを、追いかけてみようと思っている。

実装技術


この枠組みで、モデリングができれば、それは、そのまま、具体的な実装技術にマッピングができる。

REST 層は、もちろん、そのまま REST API として実装できる。
EDA 層のイベントの扱いは、 メッセージングサービス用のミドルウェア ( MOM ) とか、Mule ESB のようなフレームワークで実装できる。
データの記録層は、もちろん、データベースと、O-R マッピングのフレームワークなどが実装できる。

今回は、意識的に、「画面アプリ」、画面の MVC については、触れていない。
この「状態の変化」のモデリングの枠組みと、「画面アプリ」という実装技術の問題は、別の記事で書く予定です。

REST と画面アプリというテーマになるかな。

コメント
コメントする









この記事のトラックバック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