メディア

ドメイン層をシンプルに作るためのO-Rマッピング：保守性・拡張性に優れたシステムを作る（10）（2/2 ページ）

» 2007年09月13日 12時00分公開

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

前のページへ 1|2 　　　　　　

ドメイン層とパーシステンス層の組み合わせ

　ドメイン層のパターンはパーシステンス層のパターンと組み合わせて使用します。どのような組み合わせが考えられるかを見てみましょう。

図3 組み合わせのパターン

（1）パターン1

　Transaction Scriptは手続き型の処理なので、必要なデータをデータベースからその都度参照・更新することになります。そのため、行レベルかテーブル単位でのデータを扱うのが一番適しています。パターンとしてはTable Data GatewayかRow Data Gatewayが適しています。また、サービス層とドメイン層のサービスプロセスとビジネスロジックは、手続き型の処理を行うために分離が難しくなります。

　基本的には、論理テーブル構造をそのままサービス層で利用するようになります。そのため難しいO-Rマッピングは行わず、オブジェクトプールも利用することはありません。

（2）パターン2

　Table Moduleは、ドメイン層のロジックは非接続型のデータセットを利用して、データベースを参照・更新します。ドメイン層のクラス間では非接続型のデータセットを受け渡して処理を進めていきます。

　対応するパターンは、Table Data Gatewayになります。

　このパターンは、非接続型のデータセットをサポートしているマイクロソフト社のADOやADO.NETなどを利用することができます。

　このパターンもパターン1と同様、基本的に論理テーブル構造をそのまま利用する方式です。

（3）パターン3

　Domain Modelは、概念モデルの構造を忠実に実装します。そのため対応するパターンはDataMapper かActive Recordが対応します。ただしActive Recordは、テーブルの行との対応関係になるので、ドメイン層のエンティティ構造をテーブルの行を意識した構造に変換する必要があります。

　概念モデルを忠実に実装したい場合は、DataMapperを選択することになります。DataMapperはO-Rマッピングを実現するために、図2で示すようなドメインマネージャやパーシステンスマネージャの機能を実現し、オブジェクトプールなどを利用する必要があります。そのためかなり難しい仕組みになります。

最適な選択とは

　それでは、どのパターンが最適なのでしょうか。それぞれのパターンの特徴を考えてみましょう。

パターン	特徴	インピーダンスミスマッチ	難易度
パターン1	（1）手続き型の処理なので理解しやすい（2）複雑なシステムでは、重複した機能が増えてくる（3）複雑な概念モデルを実現することは難しい	［高］基本的にリクエスト、機能単位でのモジュール化になるので、概念モデルにおけるクラスの関係を実現するオブジェクト指向分析モデルには合わない	低
パターン2	（1）非接続型データセットを利用することにより、 SQLなどの永続化関連のコードがビジネスロジックに混在しない（2）概念モデルをそのまま実装はできない（3）ドメイン層でのオブジェクト指向的な技術が制限される（継承が使えないなど）	［中］	中
パターン3（DataMapperを選択）	（1）概念モデルの内容を、比較的変更せずにドメイン層に実装できる（2）継承やインターフェース、隠蔽などのオブジェクト指向技術が利用できるのでコンポーネント化がしやすい（3）ビジネスロジックの重複が少なくなる（4）拡張性･保守性は高い（5） O-Rマッピングの仕組みが複雑になり難易度は高い	［少］オブジェクト指向分析・設計・実装とモデルの変換が少なくシームレス	高

　どのパターンを利用するかは次のように考えられます。

（1）パターン１

ビジネスロジックが比較的簡単なシステムのとき
システムに、それほど拡張性・保守性が求められないとき
プロジェクトがオブジェクト指向開発の経験が浅く、システムの納期が短い場合
構造化設計に慣れた開発要員が多数のとき

（2）パターン2

非接続型データセットが、フレームワークでサポートされている場合

（3）パターン3

保守性・拡張性を求められる場合
概念モデルが複雑な場合
プロジェクトがオブジェクト指向開発の経験が豊富な場合

　システムのアーキテクチャは慎重に選択する必要があります。パターン３が理想的ですが、すべてのシステムに採用するべきではありません。概念モデルやビジネスロジックが複雑でない場合は、パターン1が最適です。マイクロソフトのフレームワークを採用している場合は、パターン2が良いかもしれません。

　システムに要求されている拡張性や保守性のサービスレベルを考え、開発プロジェクトのスキルを考えて選択しなければなりません。また、保守を担当する開発者のスキルも考えておく必要があります。パターン3は難易度が高いのでシステムは構築できても、保守を担当する開発者のスキルが不足してシステムを理解することができないかもしれません。

　画一的に決めるのではなく、それぞれの特徴を理解し、システムが置かれた環境を考慮して検討する必要があります。

　また、最近はO-Rマッピングツールも多く出てきています。

　EJB 2.0は、EntityBeanを利用することにより、O-Rマッピングを行います。一意性の管理やオブジェクトプールの利用、データベースとの同期などはEntityBeanがすべて行います。ただし、継承やポリモーフィズムは利用することが難しく、忠実なO-Rマッピングはできません。

　そのほかにも、HibernateやJDOなどのO-Rマッピングのツールがありますし、今後はEJB 3.0などが選択肢に入ってくるでしょう。さらにオブジェクトデータベースもありますが、性能的な面で一般的ではありません。

　それぞれのツールには一長一短があるので、よく検討して利用するのがよいでしょう。特にDomain Mapperなどを使う場合は、難易度が高いのでO-Rマッピングツールを検討することがいいでしょう。

システム化の目指すところ

　このように概念モデルを忠実に実現するのは、O-Rマッピングを考えると難しいことです。できれば、Transaction Scriptを利用して簡単に考えることができると助かります。しかし、実現したいITシステムに要求されることは、ますます複雑・大規模になり、高い拡張性や保守性が求められています。この複雑なシステムを実現することは簡単ではありません。

　それではどうすればよいのでしょうか？それは、顧客の要求を満たす最小完備な機能を備えたシンプルな構造のシステムを構築することです。

［拡張性・保守性を高めるためには］

顧客の要求を満たす最小完備な機能を備えたシンプルな構造のシステムを構築する

　この「シンプルな」というのがポイントです。シンプルな構造とは決して簡単な構造ではありません。複雑な構造を、オブジェクト指向技術（抽象化、ポリモーフィズム、隠ぺい、コンポーネント化、O-Rマッピング等など）を駆使して、本質を見極めたシンプルな構造の組み合わせにより実現します。

　概念モデルを忠実に実現することは難しいですが、これらの技法を習得した人たちには、シンプルな構造として理解しやすいシステムになります。

　例えば、ある図形の面積を計算することを考えてみます。四則演算だけで計算するのか、積分により計算するのかには、それぞれ使い分けをします。

　三角形や四角形の面積を計算するときは、四則演算だけでできます。複雑な形でも、正方形がいくつ入るかを計算すれば近似的に四則演算でできます。

　それに対し、積分はまずモデルを考えます（数式モデル）。求めたい図形を数式でモデル化し、それに対して積分を行います。考え方は積分を理解していないと難しいですが、作り上げた数式モデルは、シンプルで理解しやすいものです。また、同じような図形に応用ができます。

　このように複雑なものをシンプルに理解することは難しいですが、拡張性・保守性の観点からは、非常に重要なことです。

　オブジェクト指向を利用して、シンプルなシステムを作り上げられれば、こんなにうれしいことはありません！

　次回は、オブジェクト指向開発において保守性・拡張性を開発プロセスからどのように実現していくかを考えていきます。

参考文献

▼UMLに基づくオブジェクト指向分析設計実践（IBM Rational）

▼エンタープライズアプリケーションアーキテクチャパターン（翔泳社、マーチン・ファウラー）

▼J2EEパターン（日経BP社、Deepak Alur、John Crupi、Dan Malks）　

筆者プロフィール

野村佳弘（のむらよしひろ）

「保守性・拡張性に優れたシステムを作る」バックナンバー