ユーザが、知りたいことを知る方法は、大きく二つ。
A.自分から、情報を取りに行く ( active )
B.通知を受け取る ( passive )
エンタープライズアプリケーションの多くの機能は、どちらかの方法で、「ユーザが情報を知る」ためのサービス。
アーキテクチャとしては、REST スタイルで、 URI を指定して、GET 要求をするパターンですね。
画面系のアプリケーション。
業務的には、残高照会とか、在庫照会とか、いわゆる「照会」系の機能。
検索機能とか、一覧機能も全部、これですね。
この場面での設計課題は基本的に二つ。
(1)ほしい情報の特定方法(識別方法)
(2)ほしい情報の表現方法(表現形式)
銀行口座であれば、「口座番号」で特定する。
表現方法も、「残高」を「金額」として表現すればよい。
実際の業務でも、もちろん、もっと複雑な課題がいろいろあるけど、
・識別キーの設計 ( URI 設計)
・表現の設計 ( XML 、HTML、JSON, CSV, PDF などの出力フォーマット )
が2大テーマ。
表現の設計は、XML,JSON,CSV のように、論理構造だけ設計するケースと、HTMLやPDF のように、体裁(視覚表現)まで設計するケースがある。
ユーザが、関心のある「なにか」が起きたら、それをユーザに通知するパターン。
アプリケーションの実装手段としては「電子メールで通知」が多い。
・振り込みがあったら、連絡する。
・応募があったら、通知する。
・審査結果を通知する。
...
これも、さまざまなシーンがある。
REST スタイルの情報提供に比べると、設計課題は少しややこしくなる。
ここらへんは、マーチンファウラーの Domain Event パターンの議論が参考になる。
関心事オブジェクト(Subject) の特定は、REST スタイルの GET 方式と同じで、識別キーの設計(URI設計)が、基本課題の一つ。
大きな設計課題は、EventType の設計。
関心事オブジェクトの、どんな「状態の変化」に関心があるか、というモデリングと設計ですね。
関心事オブジェクト自体は、さまざまな属性が、いろいろタイミングで変化する。
例えば、「顧客」というオブジェクトから辿る情報として、取引履歴は頻繁に変わるし、連絡先とか、請求先も、変わる可能性がある。
購入の累積ポイントで、特別なサービスの権利を持つかもしれないし、与信限度額を超えて、一時的に受注不可になっているかもしれない。
すべての変化の可能性を列挙して、10も20もの EventType を設計するのが、完全なアンチパターン。
「連絡先」に変化と、「取引履歴」の変化は、別の関心事。
「与信限度額」とか「累積ポイント」とかは、取引履歴に関連はするけど、それぞれ、別の関心事。
こういう関心事を分類整理して、役にたつ「Event Type」のセットを設計するのが、重要な設計課題ですね。
イベント(状態の変化)に注目したアプリケーション機能の設計は、Event Type の設計がキモだし、ここがすっきりすれば、わかりやすく役に立つソフトウェアになることまちがいない。
「状態の変化」を表現する 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 あたりで、いろいろ実践しながら、ノウハウを習得していきたいと思っている。
A.自分から、情報を取りに行く ( active )
B.通知を受け取る ( passive )
エンタープライズアプリケーションの多くの機能は、どちらかの方法で、「ユーザが情報を知る」ためのサービス。
情報を取りに行く
アーキテクチャとしては、REST スタイルで、 URI を指定して、GET 要求をするパターンですね。
画面系のアプリケーション。
業務的には、残高照会とか、在庫照会とか、いわゆる「照会」系の機能。
検索機能とか、一覧機能も全部、これですね。
この場面での設計課題は基本的に二つ。
(1)ほしい情報の特定方法(識別方法)
(2)ほしい情報の表現方法(表現形式)
銀行口座であれば、「口座番号」で特定する。
表現方法も、「残高」を「金額」として表現すればよい。
実際の業務でも、もちろん、もっと複雑な課題がいろいろあるけど、
・識別キーの設計 ( URI 設計)
・表現の設計 ( XML 、HTML、JSON, CSV, PDF などの出力フォーマット )
が2大テーマ。
表現の設計は、XML,JSON,CSV のように、論理構造だけ設計するケースと、HTMLやPDF のように、体裁(視覚表現)まで設計するケースがある。
通知を受け取る
ユーザが、関心のある「なにか」が起きたら、それをユーザに通知するパターン。
アプリケーションの実装手段としては「電子メールで通知」が多い。
・振り込みがあったら、連絡する。
・応募があったら、通知する。
・審査結果を通知する。
...
これも、さまざまなシーンがある。
REST スタイルの情報提供に比べると、設計課題は少しややこしくなる。
ここらへんは、マーチンファウラーの Domain Event パターンの議論が参考になる。
関心事オブジェクト(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 あたりで、いろいろ実践しながら、ノウハウを習得していきたいと思っている。