連載 アプリケーション・アーキテクチャ・ガイド2.0解説 第4回 論理階層とコンポーネントに分解したアプリケーション・アーキテクチャ 日本ユニシス　猪股 健太郎 2009/08/18
Page1 Page2 Page3

■ビジネス層

　この層では、システムの中心となるビジネス・ロジックを実装する。トランザクションの管理もここで行う。含まれるコンポーネントの種類は以下のとおりである。

• アプリケーション・ファサード：ビジネス層のコンポーネントが持つインターフェイスを、アプリケーションやサービスに適した形に変換する。例えば、ビジネス・コンポーネントを複数回呼び出す代わりに、アプリケーション・ファサードを1回呼び出すだけで済むようにするなど。

• ビジネス・コンポーネント：ビジネス・ルールを実装し、ビジネス・タスクを実行することに責任を持つ。

• ビジネス・ワークフロー：複数の手順を含むビジネス・プロセスの定義と調整を担当する。ビジネス・プロセスは長期に渡ることもある。

• ビジネス・エンティティ・コンポーネント：コンポーネント間のデータの受け渡しに用いられる。製品や注文など、ビジネス上で意味を持つ存在を表現することが多い。

　アプリケーション・ファサードはAAGから追加されたコンポーネントである。ビジネス・ロジックの再利用性を重視すれば、ビジネス・コンポーネントの粒度やインターフェイスは呼び出し元にとって都合のよいものにならない場合がある。そのような場合はアプリケーション・ファサードがあると便利である。そうでなければ必ずしもアプリケーション・ファサードを置く必要はない。

　ビジネス層の設計手順として提案されているのは以下である。

• ビジネス層の概要を設計する：ビジネス層の呼び出し元（例えば、Webアプリケーションや外部サービスなど）を洗い出す。次に、それぞれに対する公開方法（例えば、直接呼び出すのか、サービス層を介するのかなど）を決定する。その後、セキュリティ、入力値検証、キャッシュ、例外管理の方式を決定する。

• ビジネス・コンポーネントとアプリケーション・ファサードを設計する：ビジネス・ロジックをどのように分割するか、ビジネス・コンポーネントが公開するメソッドのシグネチャ（＝名前や引数や戻り値）をどうするかを設計する。次に、アプリケーション・ファサードを置くかを決定する。その後、トランザクション方式を決定する。

• ビジネス・エンティティ・コンポーネントを設計する：データを設計し、保持する型を決定する。実装方式として、独自のクラスを作成するか、シリアル化をどう実装するかを決定する。

• ビジネス・ワークフローを設計する：データにひも付いた一連の処理を実行する場合、ワークフローが必要かを検討する。その後、認証方式を決定し、ビジネス・ルールを配置し、実装方式を決定する。

　全体的な推奨事項は以下である。

• ビジネス層に、ほかの層のロジックを混ぜるべからず

• 共通的なビジネス・ロジックは再利用するべし

• ビジネス層の呼び出し元を明確にするべし

• ビジネス層が別マシンから呼び出されるときは、呼び出し粒度を大きくするべし

• 論理階層（レイヤ）間の結合度を密にするべからず

　ビジネス層には保守性と再利用性が要求されることが多いことから、このようなアドバイスが示されているのであろう。

　最後に、アーキテクチャ・フレームの概要を説明する。

• 認証：ビジネス層がプレゼンテーション層やサービス層と同じ物理階層（ティア）に置かれているなら、ビジネス層での認証は不要となる。その場合でも、ビジネス層以降の承認メカニズムに合わせてセキュリティ情報を引き渡す。

• 承認（認可）：ほとんどの場合、ロール・ベースの承認でよい。

• ビジネス・コンポーネント：要件によってはビジネス・プロセスをコンポーネントに切り出したり、ルール・エンジンの採用を検討したりする。

• ビジネス・エンティティ：関連するアーキテクチャ・パターンを検討する。書籍「エンタープライズアーキテクチャパターン」（ファウラー、翔泳社、978-4798105536）が参考になる。

• キャッシュ：パフォーマンスと応答性を上げるためにデータのキャッシュを検討する。

• 凝集度と結合度：コンポーネントの凝集度を高くする。また、レイヤ間の結合度は疎にする。疎結合のためにはインターフェイスを活用し、抽象化を図る。

• 並列性とトランザクション：データやリソースの共有を分析したうえで、同時実行制御とトランザクションを設計する。ロックは極力短くする。

• 例外管理：いつ、どこで、どのような例外を処理するかの方針を決め、一貫性を持たせる。論理階層（レイヤ）の境界でエラー・ログを記録することを検討する。

• ロギングと計測：ビジネス処理のログはセキュリティ的にも重要な意味を持つ。

• 入力値検証：入力値はビジネス的な整合性が保たれているかを検証する。

■データ・アクセス層

　この層では、データソースのデータにアクセスするためのロジックを実装する。含まれるコンポーネントの種類は以下のとおりである。

• データ・アクセス・コンポーネント：データソースが保持しているデータの取得と操作を担当する。

• サービス・エージェント：サービスへのアクセスを担当する。サービスとの契約を実装する部分はコンポーネント内部に隠ぺいし、アプリケーションに適した形のインターフェイスを公開する。

• データ・ヘルパー＆ユーティリティ：データ・アクセス層に含まれる複数のコンポーネントに共通する処理を担当する。データソースにアクセスする処理の中でアプリケーションに依存しない部分を実装する。AAfNでも言及はされていたが、AAGでは正式にコンポーネントとして抽出され、図にも明記された。

　データ・アクセス層の設計手順として提案されているのは以下である。

• データ・アクセス層の概要を設計する：データソースに関係する要件を洗い出し、データソースとの接続方式や、データ構造とのマッピング方式を決定する。そして例外の処理方針を決定する。

• データ・アクセス・コンポーネントを設計する：RDB（＝リレーショナル・データベース）のテーブルなどのデータ集合ごとに、アクセス・メソッドを設計する。デザイン・パターンの適用も検討する。

• データ・ヘルパー・コンポーネントを設計する：各データ・アクセス・コンポーネントに共通するロジックを抽出してまとめる。

• サービス・エージェントを設計する：プロキシ・クラスやデータ・クラスを自動生成するツールを活用する。

　全体的な推奨事項は以下である。

• データ・アクセス機能の詳細を隠ぺいするべし

• アプリケーションが扱うエンティティとデータ構造とを対応付ける方法を決めるべし

• コネクション情報の管理方法を統一するべし

• セキュリティ上のリスクを考慮すべし

• データベースへのアクセス回数を減らすべし

• パフォーマンスとスケーラビリティに関する要件を反映させるべし

　データ・アクセス層は論理階層（レイヤ）の最下層に位置し、アプリケーション全体に与える影響が大きい層である。従って細心の注意を払って設計する必要がある。

　最後に、アーキテクチャ・フレームの概要を説明する。

• BLOB：サイズの大きなバイナリ・データを格納する型である。データが何らかの構造を持っていた場合でも、BLOBとして格納してしまうとDB（＝データベース）にはそれが分からない。また、データの検索が困難になる。よって採用に当たっては、よく検討しなければならない。

• SQLのバッチ処理：複数のSQL命令を1回の送受信で実行させることでパフォーマンスを向上できる。同じようなSQL命令を続けて何度も発行するような場合に採用するとよい。

• コネクション：コネクションの作成／管理／解放はデータ・アクセス層で統一的に行わなければならない。

• データ・フォーマット：ほかの層とのやり取りにどのような型を用いるかを決定する。

• 例外管理：デッド・ロックやコネクション・エラーにどう対処するか、DBの制約違反を上位層にどのように伝えるかなどの方針を定める。

• ORマッピング：オブジェクト指向設計を採用するのであれば、ORマッピングのフレームワークを検討するとよい。その際、DBスキーマは変更可能か不可能かに注意する。

• クエリ：主にセキュリティの観点から、クエリをどのように組み立てるべきかを検討しなくてはならない。

• ストアド・プロシージャ：以前はパフォーマンスの観点からストアド・プロシージャが採用されることがあったが、最近は動的SQL命令であってもパフォーマンスの低下は少なくなってきている。そのため、スキーマの抽象化や、テスト容易性や、セキュリティの観点で採用を検討すべきである。AAGではストアド・プロシージャと動的SQL命令について詳しく解説している。

• トランザクション：不要なときは使わず、必要なときもできる限り短くすること。データの一貫性と処理の並列性のトレードオフを検討すること。

• 入力値検証：信頼境界をまたぐデータは必ず検証すること。SQLインジェクションを防ぐため、数値の場合は数値以外をエラーにし、文字列の場合は適切にエスケープすること。

• XML：相互運用性のためにXML形式のデータを使うときは、データベースの型でもXML型を検討する。その際はXMLスキーマなどでデータの整合性を検証する。

■

　さて、今回は論理階層（レイヤ）の責務に着目したアーキテクチャ設計について説明した。検討すべき項目の全体像をとらえることができただろうか。詳しい情報については、ぜひAAGをお読みいただきたいと思う。

　次回以降は、いろいろなアプリケーション種別ごとに、アーキテクチャ設計のポイントを説明していく。

INDEX
	連載：アプリケーション・アーキテクチャ・ガイド2.0解説
	第4回 論理階層とコンポーネントに分解したアプリケーション・アーキテクチャ
	1．AAGの論理アーキテクチャ／レイヤとティアの選択
	2．プレゼンテーション層／サービス層
	3．ビジネス層／データ・アクセス層

「アプリケーション・アーキテクチャ・ガイド2.0解説」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）