連載

アプリケーション・アーキテクチャ設計入門

第3回 論理アーキテクチャを構成するコンポーネントの設計（ビジネス／データ層編）

日本ユニシス　猪股 健太郎
2003/10/25

特徴

• 呼び出しをまたいで状態を保持しない

• 1つのデータアクセス・ロジック・コンポーネントは1つのデータソースだけにアクセスする

• ほかのデータアクセス・ロジック・コンポーネントを呼び出さない

• 複数トランザクションを開始しない

役割

• エンティティに対する操作として、一般的にCRUD（Create、Refer、Update、Delete）のメソッドを提供する

• 主となるテーブルに作用するだけでなく、関連テーブルの操作も実行する

• 複数のテーブルを連結し、読み出し専用でデータを取得する

• データを更新して再取得する

• エンティティのスキーマやクエリのパラメータなどのメタデータを返す

• ユーザー・インターフェイスのために、結果セットをページングする

　これらに加えて、楽観的ロックのカプセル化や、トランザクションに関係しないクエリ結果のデータ・キャッシュなどを実現するユーティリティ・コンポーネントを用意しておいて、適宜呼び出すこともする。また、大規模なシステムで、データを複数のサーバに分散させる場合は、データを動的にルーティングする。

推奨

• 必要なデータだけを返す

• 特定のスキーマからデータアクセスを抽象化するためストアド・プロシージャを使う。ただし、ストアド・プロシージャを使いすぎるとコードの保守性や再利用性が悪くなるため注意する

• データ操作は可能な限りRDBMSで実行させる

• Insert、Read、Update、Findなど、よく使われる機能はストアド・プロシージャで実装する

• すべてのデータアクセス・ロジック・コンポーネントに共通な機能はインターフェイスや基本クラスとして公開する

• 異なるクライアントに対しても一貫したインターフェイスを設計する。例えば、インターフェイスの設計がビジネス・コンポーネントの実装に依存しないようにする

• スキーマやカラム名などのメタデータを公開する

• エンティティの関連を表現するテーブルについては、対応するデータアクセス・ロジック・コンポーネントを作らない。例えば、書籍と著者の関連をTitleAuthorテーブルで表現している場合は、著者テーブルにアクセスするデータアクセス・ロジック・コンポーネントにAddBookメソッドを用意するか、書籍テーブルのデータアクセス・ロジック・コンポーネントにAddAuthorメソッドを用意する

• データを暗号化して保存するなら、データアクセス・ロジック・コンポーネントが復号化を処理する

• ビジネス・コンポーネントをエンタープライズ・サービスで実装する場合は、データアクセス・ロジック・コンポーネントもサービス・コンポーネント化する。エンタープライズ・サービスを使っていないか、アプリケーション・ドメインをまたがる呼び出しがないのであれば、サービス・コンポーネントにしなくてもよい

• トランザクション分離レベルを検討する。パフォーマンスが要求される場合は低いトランザクション分離レベルで動作する特別な操作を用意してもよいが、異なるトランザクション分離レベルを結合させるとデータの一貫性に悪影響を及ぼすので注意する

役割

　サービス・エージェントは以下のことを実現するために使用する。

• 1つのサービスに対するアクセスをカプセル化する

• 外部サービスのデータ・フォーマットやスキーマの変更がビジネス・プロセスに影響を及ぼさないようにする

• ビジネス・コンポーネントに対し、統一的な入出力フォーマットを提供する

　これらに加えて、必要なら以下の処理も行う。

• 外部サービスとやりとりするデータを検証する

• 頻繁に実行される問い合わせの応答データをキャッシュする

• サービスへのアクセスを承認する

• サービスに対し、正しいセキュリティ・コンテキストをセットしたり、正しい資格情報を提供したりする

• 暗号化など、通信路のセキュリティを確認する

• 契約どおりのサービス・レベルが守られているか調べるためのモニタリング情報を提供する