PoEAA 関心事の分離の戦略

マーチンファウラーの PoEAA ( Petterns of Enterprise Application Architecture ) の関心事の分離の戦略。
戦略というか、分離の定石かな?

レイヤ

最初の戦略兵器は「レイヤ」パターン。
これはお約束ですね。

Eric Evans の ドメイン駆動設計 ( DDD : Domain-Driven Design ) でも、まず、ドメインとそれ以外の関心事の分離の基本や「レイヤ」から。

ドメイン層

関心事の中心は、ドメイン層。ドメイン層から出発する。ドメイン駆動ですね。

ドメイン層の中で、さらに関心事を分離するパターンは、Evans の DDD が必読。

 ビジネスパターンによるモデル駆動設計 や「アナリシスパターン」もビジネスの関心事を分離するパターンカタログとして、参考になりますね。

データソース層

次に進むのは、データソース層の課題。

ファウラーの PoEAA では、永続化、それも、リレーショナルデータベースとオブジェクトとのマッピング ( O-R マッピング ) にフォーカスしている。

ファウラー自身が PoEAA の「まえがき」で書いているように、アプリケーション連携、特に、メッセージングによる連携が、永続化とならぶ、重要な関心事。

メッセージングとアプリケーション連携のパターンカタログとしては、
EIP : Enterprise Integration Pattern
が参考になります。

データソース層のアーキテクチャパターンの実装は、オープンソースのフレームワークがいろいろ使える。

Webプレゼンテーション層

次の重要課題は、ユーザインタフェース、特にWebアプリケーションのプレゼンテーションの課題。
利用者から見たら、プレゼンテーション層だけが、ソフトウェアシステムの実体。

プレゼンテーション層のパターンの実装も、フレームワークとか、ライブラリがありますね。
データソース層に比べると、構造や振舞が、ぎこちないものが多く、未成熟な分野かな?

その他の関心事

PoEAA ではパターン化されていない主な関心事は、

・セキュリティ
・バリデーション
・エラー処理
・リッチクライアント
・クラスタリング
...

まあ、ここらへんは、自作することも多いし、Spring フレームワークや、オープンソースのライブラリが利用できる。(実際に動くパターンとして使える)

ドメイン駆動

基本は、ドメイン層中心。
他の関心事も、ドメインの概念や要求を中心に、設計、実装、検証をしていく。

結果的に、ドメイン以外のレイヤにも、ドメインの概念(用語)がたくさん登場する。
ユビキタス言語です。

アプリケーションのアーキテクチャ全体が、ドメイン駆動で、ユビキタス言語。

関心事は、エンタープライズアプリケーション

ソフトウェアといっても、分野は広い。
私の専門は、エンタープライズアプリケーション。

マーチンファウラーの、PoEAA( エンタープライズ・アプリケーション・アーキテクチャ・パターン)の「はじめに」を参考に、エンタープライズアプリケーションの関心事を整理すると...

永続データ

ビジネスでは、データの記録が基本ですね。
過去の事実はもちろん。
もっと重要なのは、将来の約束(予定や契約)を記録して、確実に履行することがビジネスの基本。

たくさんのデータ

ビジネスとは、ビジー(忙しい)ということ。
日々刻々データが発生します。
これを効果的に扱うには?

同時にデータアクセス

ビジネス活動で使う情報やデータは、多くのユーザが同時にアクセスする。
二人のユーザが同時に同じデータで作業する場合はどうなる?
百人、千人が同時に利用するか?もし、そうなったら、どうなる?

多くのユーザインタフェース画面

いろいろなデータ、情報を、いろいろなタイプのユーザが利用する。
何百もの異なる画面が必要。

※画面だけでなく、バッチ処理も忘れてはいけない。

他のエンタープライズアプリケーションとの連携 ( EAI )

ビジネス活動が、さまざまな活動が相互に関連している。
エンタープライズアプリケーションも、孤立して存在することはない。
エンタープライズアプリケーション間の連携が重要な関心事。

アプリケーション間の連携:多様な技術要素

データ形式、通信方式、実装技術、基盤のOSやハードウェア、...
ありとあらゆる技術要素が、混乱を拡大する。

アプリケーション間の連携の課題:概念の不一致

技術的には連携を確保できても...
「顧客」の定義が部門間や、ビジネスパートナー間で異なるのがあたりまえ。
「商品」や「在庫」、「計上ルール」、「例外の扱い」....
エンタープライズアプリケーションの連携の中核の課題は、この概念の不一致をどう扱うか?

ビジネスロジック

ビジネスの決め事は、とっても、論理的「ではない」。
唯一の真実は、ビジネスのロジック(決め事)は、時とともに、場面によって、いつも変化する、ということ。
この変化への対応の方針と手段は?_

大規模システム

ビックビジネスでは、システムも大規模になる。
(もっとも、大きくすることが最善かどうかは別問題。ビジネスもシステムも、自律的に活動するユニットの緩やかな連携が、良いことも多い)

小規模なシステムの累積効果

ひとつひとつのエンタープライズアプリケーションは、小規模では、ビジネス活動全体では、それが集まって、連携して、さまざまな価値を生んだり、逆に、ビジネスの障害になる。

小さいなエンタープライズアプリケーションの質を地道に改善する。その累積の効果は、ビジネスにとって、大きな影響がある。

ずさんな小さなソフトウェア開発プロジェクトの(マイナスの)累積結果に苦しんでいるのが、多くの現場の実態ですね。

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