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

» 2007年02月21日 12時00分 公開
[野村佳弘，日立ソフトウェアエンジニアリング]
前のページへ 1|2|3|4 　　　　　　

それぞれのパターンの難易度

　それでは、拡張性・保守性を高くするパターンはどれでしょうか？ オブジェクト指向という観点から見ると、Domain Modelが最適に思えますが、そうなのでしょうか？

　それぞれ のパターンの難易度を考えてみましょう。

　難易度とは、2つの考え方があります。1つは「システムが複雑で難易度が高い」のと、もう1つは「開発技法の考え方が難しい」ことです。

　「システムが複雑で難易度が高い」とは、業務的、システム的に要求が高く、実現しようとしているシステムが複雑であるために、難易度が高い場合です。

　また、「開発技法の考え方が難しい」とは、オブジェクト指向技術などを利用した場合など、モデリングやイテレーション開発などの難解な技術を利用しなければならないので難易度が高くなります。

（1）ビジネスロジックが複雑で難易度が高い

　ドメイン層では、「システムが複雑」を「ビジネスロジックが複雑」と考えて話を進めていきます。「ビジネスロジックが複雑」と「拡張性・保守性の難易度」を、それぞれのパターンにおける関係を図4に示します。右にいくほどビジネスロジックが複雑になり、上にいくほど拡張性・保守性が低くなります。

ALT 図4 それぞれのパターンにおける関係

　図4に示すように一般的にビジネスロジックの複雑さが高くなると、拡張性・保守性が低くなります。従って、拡張性・保守性を高くするためには以下の方法が考えられます。

  1. ビジネスロジックを複雑にするような機能要件をなくし、簡単にする
  2. ビジネスロジックが複雑な場合、Domain Modelを利用し保守性・拡張性を確保する

　（1）の選択をした場合は、ビジネスロジックの複雑さ自体が少なくなったので、図4からTransaction Scriptのパターンを選択するのが一番、拡張性・保守性が高くなります。

　（2）の選択をした場合は、Domain Modelを選択することにより、抽象化や関連、カプセル化などのオブジェクト指向技術で複雑なロジックを整理整頓して簡単な構造の組み合わせで実装できるようにします。無駄のない最小完備でシンプルなシステムを作ることにより、拡張性・保守性を高めます。

　Table ModuleはTransaction ScriptとDomain Modelの中間的なパターンと考えることができます。

（2）開発技法の考え方が難しい

　システムが複雑なときは、本質的なものを見つけて、複雑なものの構造を単純なものの組み合わせで構造を作り上げることができれば、理解がしやすくなります。そのためには、抽象化や関連、ポリモーフィズムなどのオブジェクト指向技術を利用します。

　抽象化などの考え方は、一般的に難しく、その技法を習得するのに時間がかかります。また、抽象化などを行い作成したモデルは、1回モデリングしただけでは、拡張性・保守性を持たせることができません。変更要求を取り入れて何回も繰り返してモデリングを行い、モデルを鍛えることにより拡張性・保守性を高めていかなければなりません（イテレーション開発）。

　オブジェクト指向開発は、このように構造化設計やウオーターフォール開発より手間が掛かります。

　Domain Modelは、オブジェクト指向分析の結果である概念モデルを基に実装するため難易度は高くなります。また、O-Rマッピングなどを行わなければならないためパーシステンス層が難しくなります。

　それに対し、Transaction Scriptは、プロセス中心の設計により、業務仕様などに示されている業務ロジックを実装すればよく、考え方は理解しやすいパターンです。（ただし、良い設計を行うのは、やはり難しいです）。

　Table Moduleは、データ分析を中心に考えていきます。やはりTransaction ScriptとDomain Modelの中間的なパターンと考えることができます

　このように、（1）と（2）から、以下のことが分かります。

  1. 複雑なビジネスロジックの拡張性・保守性を高めるためには、オブジェクト指向技術を利用したDomain Modelが適している
  2. Domain Modelはオブジェクト指向技術を利用するため、難易度が高く、誰にでも利用できるわけではない
  3. Transaction Scriptは、誰にでも理解しやすい
  4. Transaction Scriptは、ビジネスロジックが複雑になると拡張性・保守性が低くなる。

ドメイン層に最適なパターンとは？

　ドメイン層の設計をするには、スキルや拡張性・保守性のサービスレベルを考慮し3種類のアーキテクチャパターンを選択します。手続き型のアプリケーションの開発に慣れており、拡張性・保守性をそれほど求めないなら、Transaction Scriptを選択するのが良いでしょう。

　ビジネスロジックが複雑で、オブジェクト指向開発に慣れた人材がプロジェクトに存在し、高い拡張性・保守性が求められるならDomain Modelを選択することになります。

　非接続型のデータセットなどを利用でき、ビジネスロジックがテーブル構造に対応して整理できる場合は、Table Moduleも選択可能です。Table ModuleはTransaction Scriptよりは、ビジネスロジックを集約しやすく、重複を防ぐことができるので、拡張性・保守性もある程度望めます。非接続型のデータセットを利用できない場合でも、データ構造を基にして、ビジネスロジックを整理することができます。

　それぞれのパターンには特徴があり、プロジェクトの制約（拡張性・保守性のサービスレベル、技術力、性能、実績など）を考えて、最適なパターンを選択し最善な適用方法を考えていきます。

　次回は今回の続きとして、ドメイン層と関係が深いパーシステンス層について、お話ししたいと思います。

参考文献
▼UMLに基づくオブジェクト指向分析設計実践（IBM Rational）
▼今だからデータアクセスを真剣に考える！（日本オラクル、佐藤 裕之）
▼エンタープライズ アプリケーションアーキテクチャパターン（翔泳社、マーチン・ファウラー）

筆者プロフィール

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


「保守性・拡張性に優れたシステムを作る」バックナンバー
前のページへ 1|2|3|4 　　　　　　

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ