ドメイン層に最適なアーキテクチャを考える：保守性・拡張性に優れたシステムを作る（8）（3/4 ページ）

[野村佳弘，日立ソフトウェアエンジニアリング]

（A）Transaction Script

　Transaction Scriptはドメインロジックを機能別に分け1つのプロシージャとして実装します。1つのプロシージャから複数のテーブルにアクセスする場合があります。一般的なアプリケーション開発ではよく見られるパターンです。機能別に作られたプロシージャは、必要なデータをパーシステンス層に依頼しValueObjectなどで取得したビジネスロジックを実行します。ValueObjectは参照に利用し、更新・削除はパーシステンス層のメソッドを利用します。

　ただし、Transaction Scriptはプロセス中心の処理になりやすく、サービスプロセスとビジネスロジックが分離しにくい場合があります。そのため、Transaction Scriptを利用するときは、サービス層とドメイン層を1つの層にすることも検討します。

　Transaction Scriptパターンはエンティティクラス内にデータを保持しません。ステートレスなクラスの場合が多くなります。テーブルに存在する永続化データを、パーシステンス層を利用して直接参照・更新します。

図1 Transaction Scriptパターン

• トランザクションまたは機能単位でメソッドを実装する（プロセス中心の設計）
• ドメイン層のエンティティクラスから複数のテーブルにアクセスする
• 手続き型の処理ロジックなので考えやすい
• ビジネスロジックとサービスプロセスが混在してしまう
• システムが複雑になると、ビジネスロジックが複雑になり設計や保守が難しくなる

（B）Domain Model

　Domain Modelでは、概念モデルでの継承や関連で関連付けられているクラス構造を、ドメイン層でエンティティクラスの構造として設計します。

　一般的に概念モデルとリレーショナルデータベースのテーブル構造は一致しません。そのため、Domain Modelを概念モデルの構造で設計した場合、パーシステンス層では、テーブル内のデータ項目と概念モデルのエンティティクラス内のデータ項目とのマッピングを行わなければなりません。これをO-Rマッピングといいます。

　Domain Modelでは、ドメイン層は概念モデルを実装できますが、O-Rマッピングは複雑になるため、パーシステンス層の設計や考え方は難しくなります。

　O-Rマッピングはパーシステンス層の役割です。ドメイン層でデータベースのテーブル構造などを意識する必要はありません。理想的には、ドメイン層のエンティティクラスはテーブルの構造やデータを意識することなく、背後でパーシステンス層がテーブルのデータを更新します。

図2 Domain Model

• オブジェクト指向分析に従って、抽出された概念モデルを基に実装する
• エンティティクラスのデータとテーブルのデータをO-Rマッピングにより対応を取る
• 継承やポリモーフィズムなどを利用したオブジェクト指向的な実装が可能
• ビジネスロジックを適材適所に配置することが可能
• 継承、関連などのオブジェクト指向技術を利用して拡張性・保守性の高いシステムを作ることが可能
• O-Rマッピングを行うパーシステンス層が複雑になり設計が難しい

（C）Table Module

　Table Moduleはデータベースのテーブルに関連したビジネスロジックを1つのエンティティクラスとして実装します。複数のテーブルを利用するビジネスロジックは、コントロールクラスとしてエンティティクラスとは別にすることもあります（図3の貸出クラス）。

　サービス層のサービスプロセスを実現するロジックから、テーブルに対応したビジネスロジックを呼び出し、処理を進めていきます。ビジネスロジックが利用するデータはテーブル上のデータになります。

　ここで非接続型のデータセットの利用を考えてみましょう。非接続型のデータセットは、データベースとの接続を切断した後でも、データを利用できる仕組みです。エンティティクラスではこの非接続型データセットをビジネスロジックから利用します。非接続型のデータセットには、テーブルから取得したデータがバッファされています。バッファされているデータは行や列などのオブジェクトとして利用することができます。エンティティクラスでは、非接続データセットを永続化の対象データとして使用します。

　必ずしも非接続型のデータセットをTable Moduleで利用しなければならないわけではありませんが、非接続型のデータセットを利用すると、ビジネスロジックと永続化ロジックがうまく分離できます。必要なデータはデータセットにバッファされているので、ドメイン層ではパーシステンス層から非接続型のデータベースを受け取り、受け取ったデータセットに対して、参照、更新、削除を行います。データを更新・削除した場合は、後でデータベースに対して一括更新します。

　データの操作は非接続型のデータセットが持つオブジェクト（行や列など）を操作することにより、ドメイン層ではビジネスロジックを単一のプログラム言語で記述することができます。

　このような非接続型のデータセットは、例えばマイクロソフトのADO.NETで利用することができます。

---

＊（ADO.NETについては、＠ITの「ADO.NET基礎講座」を参照してください。

---

　データ構造の分析を行い、テーブル単位にビジネスロジックが整理されるようなシステムでは、有効なパターンだと考えられます。

図3 Table Module

• 1つのテーブルに対して1つのエンティティクラスを実装する
• テーブルに関係するビジネスロジックをエンティティクラスに実装する
• 非接続型データセットを利用すると、ビジネスロジックが実装しやすい
• ビジネスロジックが、テーブル対応に整理できる場合には有効となる