イベント駆動のアーキテクチャ 【これから重要になるパターン】

ユーザが、知りたいことを知る方法は、大きく二つ。

A.自分から、情報を取りに行く ( active )
B.通知を受け取る ( passive )

エンタープライズアプリケーションの多くの機能は、どちらかの方法で、「ユーザが情報を知る」ためのサービス。

情報を取りに行く


アーキテクチャとしては、REST スタイルで、 URI を指定して、GET 要求をするパターンですね。

画面系のアプリケーション。

業務的には、残高照会とか、在庫照会とか、いわゆる「照会」系の機能。
検索機能とか、一覧機能も全部、これですね。

GET.png

この場面での設計課題は基本的に二つ。

(1)ほしい情報の特定方法(識別方法)
(2)ほしい情報の表現方法(表現形式)

銀行口座であれば、「口座番号」で特定する。
表現方法も、「残高」を「金額」として表現すればよい。

実際の業務でも、もちろん、もっと複雑な課題がいろいろあるけど、

・識別キーの設計 ( URI 設計)
・表現の設計 ( XML 、HTML、JSON, CSV, PDF などの出力フォーマット )

が2大テーマ。

表現の設計は、XML,JSON,CSV のように、論理構造だけ設計するケースと、HTMLやPDF のように、体裁(視覚表現)まで設計するケースがある。

通知を受け取る


ユーザが、関心のある「なにか」が起きたら、それをユーザに通知するパターン。

アプリケーションの実装手段としては「電子メールで通知」が多い。

・振り込みがあったら、連絡する。
・応募があったら、通知する。
・審査結果を通知する。
...

これも、さまざまなシーンがある。

SEND.png

REST スタイルの情報提供に比べると、設計課題は少しややこしくなる。

ここらへんは、マーチンファウラーの Domain Event パターンの議論が参考になる。

ドメインイベント.png

関心事オブジェクト(Subject) の特定は、REST スタイルの GET 方式と同じで、識別キーの設計(URI設計)が、基本課題の一つ。

Event Type


大きな設計課題は、EventType の設計。
関心事オブジェクトの、どんな「状態の変化」に関心があるか、というモデリングと設計ですね。

関心事オブジェクト自体は、さまざまな属性が、いろいろタイミングで変化する。

例えば、「顧客」というオブジェクトから辿る情報として、取引履歴は頻繁に変わるし、連絡先とか、請求先も、変わる可能性がある。
購入の累積ポイントで、特別なサービスの権利を持つかもしれないし、与信限度額を超えて、一時的に受注不可になっているかもしれない。

すべての変化の可能性を列挙して、10も20もの EventType を設計するのが、完全なアンチパターン。

「連絡先」に変化と、「取引履歴」の変化は、別の関心事。
「与信限度額」とか「累積ポイント」とかは、取引履歴に関連はするけど、それぞれ、別の関心事。

こういう関心事を分類整理して、役にたつ「Event Type」のセットを設計するのが、重要な設計課題ですね。

イベント(状態の変化)に注目したアプリケーション機能の設計は、Event Type の設計がキモだし、ここがすっきりすれば、わかりやすく役に立つソフトウェアになることまちがいない。

Event


「状態の変化」を表現する Event オブジェクトの基本は、

・Subject への参照 (関心事の識別キーの保持)
・Event Type への参照 ( 何が起きたかの表現)
・発生日時
・記録日時 (イベントオブジェクトの生成日時)

の4つになる。

発生日時と記録日時が同じ場合も多いけど、これ、基本パターンは、Dual 日時にしておくこのが、実践的。

ビジネスの世界では、「起きた日時」と「それを検知した日時」が、それぞれ、重要な関心事になるケースが多い。

イベントの通知(メッセージング)


イベントと、その通知(メッセージング)は、混同されることが多い。

私は、

イベント:変化があったことの表現
メッセージング:通知する行為

を明確に別のものとして考えている。

メッセージングは、「イベント」だけに限らず、「シグナル」「ドキュメント」「コマンド」など、いろいろな通知対象がある。

もちろん、イベントはただ、オブジェクトを生成しただけでは役に立たない。

ビジネスでは、関心事に変化があったら、

(1)記録 (永続化、DBへの書き込み)
(2)通知 (メッセージング)

の2つを行うのが基本中の基本。

イベント駆動のアーキテクチャ


ビジネスの道具である、エンタープライズアプリケーションは、もちろん、この「永続化」と「メッセージング」が2大テーマ。

永続化は、データベース、O-R マッピングのフレームワークなど、アプリケーション実装技術の基本だし、なじみがある。

設計という視点でも、PoEAA, DDD など、どれも、エンタープライズアプリケーションの基本課題として「永続化」を中心に議論している。

それに比べると、イベントのメッセージングは、実装技術としては、電子メール通知くらいしか、やったことがない、という技術者が多いのかな?

設計パターンの議論も「永続化」に比べたら、情報は、極端に少ない。

「永続化」の視点の設計・実装は、データモデリングとか、データベース設計やSQLという歴史がある、分野。
エンタープライズアプリケーションといえば、画面系の仕組み(MVC)+「DBアクセス」というのが基本セットですね。

最近だと、画面系は、Web が多いから、 Web + DB = アプリケーションというのが、基本パターン。

イベント駆動で考える


IT側からみると、永続化とメッセージングは、現実的に、かなり、大きさが違う存在。

設計・実装を経験する機会は、「永続化」、データベースが圧倒的に多い。

でも、ビジネス側、エンタープライズアプリケーションの利用側で考えると、このIT側の「永続化」と「メッセージング」の重さの違いは、たぶん、異常な状態。

ビジネスの活動を素直に分析、モデリングすれば、

(1)記録 (永続化)
(2)通知 (メッセージング)

は、2大重要機能なんです。

個人的には、今、ここは、ホットスポットだと思っている。

イベント駆動のアーキテクチャ、「イベント」と、その「メッセージング」を重視した、モデリングと、設計・実装が、これからのエンタープライズアプリケーションでは、必須だし、また、実現できるシステム価値も、非常に大きなものになる。

技術的にも、インターネットを支える基盤技術があって、その上で、クラウドコンピューティングという、「ネットワークベース」の技術の重みが急速に拡大している。

また、Mule ESB のように、メッセージングを扱うためのフレームワークも、だいぶ、発展してきた。

XML/JSON over HTTP のような REST スタイルの「メッセージング」も、普通に使う技術になった。

画面アプリも、伝統的な Web MVC (サーバーサイドのコントロール)だけでなく、REST スタイルのサービスを使った、アプリ サイド MVC ( クライアント側のアプリのコントロール)が、広がってきている。
特に、iPhone や、 Android では、ネットワーク上の資源を活用したアプリが一気に花開きはじめた感じ。

そういう技術面の流れと、「記録」と並んで「通知」が重要、というビジネスの本質の要求が一体となって、これからしばらくは、イベント駆動スタイルのアーキテクチャ、そのためのモデリング、設計・実装技術が、ホットスポットだと思っている。

実践して、ノウハウ習得が必要


自分自身、イベント駆動スタイルのアーキテクチャに経験が多いわけでもないし、勉強しようにも、参考情報がなかなか見つからない、というのが実感。

EIP:Enterprise Integrations Patter とか、前述の、ファウラーの Domain Event の議論とかは、貴重な参考情報だと思っている。

これと、ドメイン駆動設計の考え方、設計手法としては、神崎さんの RDRA ( リレーションシップ駆動分析)と、ICONIX 、実装技術として、Mule ESB メッセージングフレームワーク、基盤技術として、 Java/Spring あたりで、いろいろ実践しながら、ノウハウを習得していきたいと思っている。

calendar
  12345
6789101112
13141516171819
20212223242526
27282930   
<< June 2010 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM