<< 分析パターン : これだけは覚えておこう | main | ドメインを深く理解するためのリファクタリング >>

ドメイン駆動設計と「デザインパターン」の関係

GoFの「デザインパターン」は、ドメイン駆動設計と、どう関係するか?

これが、Domain-Driven Design(DDD)の 12章 "Relating Design Patterns to the Model" のテーマですね。

読み替えが必要


エバンスは、

・「デザインパターン」は、ドメインモデリングにも参考になる
・しかし、利用にあたっては、「別の考え方」をする必要がある

と言っている。

GoFの「デザインパターン」は、汎用的だけど、「テクニカル」な実装の問題の解決に重点がある。
原典が、元々、そういう視点。そして、解説本やサンプルになると、さらに「実装技術」に偏った内容が多くなる。

ドメイン層のモデリング、設計にも利用は可能だけど、「テクニカル」な側面、「実装」内部の問題は、切り離して、「概念」レベルのパターンとして利用すべき。

ドメイン層の表現手段として役に立つことはある。
それと、「デザインパターン」そのままに設計・実装するかは、別の問題。

こういう内容を、

・Strategy パターン
・Composite パターン
・Flyweight パターン

を例に説明している。

Strategy パターン


適切な「輸送ルート」を見つける「ロジック」を例に、説明している。

「輸送ルート」は、「時間が最短」で見つける方法と、「費用が最小」で見つける方法がある。
「乗換案内」とかもそうですね。

複数の「ルート」案を比較するロジックとして「時間で計算」と「費用で計算」という二つの方法がある。

これは、概念的には、 Strategy パターンの適用分野。

GoF「デザインパターン」では、Strategy パターンは、動的に、ロジックを入れ替えることを重視した説明になっている。

エバンスは、そういう側面より、「複数のロジックを別のオブジェクトに分けて表現」するとわかりやすくなる、という点を重視している。

実際、モデル図でも、本来の Strategy パターンとは、違う使い方をしている。

元々のパターンでは、 Context オブジェクトが、Strategy への参照を保持する構造。

エバンスの例では、「ルートを見つける」メソッドへのパラメータとして、Stragegy オブジェクトを使うだけ。「参照」ではなく「利用」という関係に変えている。

このほうが、モデルも実装も単純で、少なくともサンプルの「適切な輸送ルート」という問題では、このほうが、わかりやすい。

また「動的」な追加みたいなことは、重視していない。
業務ルールはほぼ固定だけど、「複数の計算方法がある」ことを、明示する手段として Strategy パターンを参考にしてみた、という感じですね。

別に Strategy パターンでなくても良くて、ファウラーの「リファクタリング」9章「条件記述の単純化」のやり方で、うまく表現できれば、それでも良い。

Composite パターン


ビジネス領域でも、Composite パターンが適用できそうな課題はいくつかある。
DDD の例では、「輸送ルート」全体は、個々の「輸送ルート」の合成、という例であげている。

つまり「全体」も「部分」も「輸送ルート」として扱える、ということ。

製造業の部品表(BOM) とか、組織構造とかも、「部品」が集まって「部品」、「組織単位」が集まって「組織単位」という構造になっている。 Composite パターンが利用できる「可能性」がある。

でも、エバンスは、

・ほんとうに、どこをとっても「全体」と「部分」は同じインタフェースで扱えるのか?
・無限に広がるネスティングが、ほんとうに必要か?

をちゃんと検討すべきだといっている。

Composite パターンは、とても汎用的だから、ある意味、なんでも表現できちゃう。

でも、Composite パターンで表現することが、今の問題領域(ドメイン)の構造を、適切にわかりやすく表現する手段なのか、ちゃんと検討したほうが良い。

DDD の12章の例でも、「全体ルート」とそれぞれの「部分ルート」は、全て同じインタフェースで扱うという、Composite パターンよりも、

・倉庫からの出荷
・アメリカ国内輸送
・外洋の航海(サンフランシスコから横浜とかね)
・日本国内輸送
・届先への配達

というように、「役割」が異なった部品に分解するモデリングを説明している。

ニュアンスとしては、Composite パターンの利用には消極的ですね。

自己参照テーブル


Composite パターンを、テーブルで表現すると方法として、自己参照テーブルがある。

Oracle のサンプルテーブルの EMP テーブルが、このパターンの例ですね。

従業員の上司は別の従業員という構造を、ひとつの EMP(従業員)テーブルで、表現している。

従業員レコードが、別の従業員レコードを参照するので、「自己参照」テーブルという。

「自己参照テーブル」は、とても汎用的で、利用可能な範囲は広い。

でも、ある特定の問題領域のソリューションとしては、「汎用的」すぎるケースがほとんど。

Compoiste パターン、自己参照テーブルは、「無限」のネスティングができる設計パターン。

でも、それが「ドメイン」の構造の、もっとも適切な表現がどうかは疑問。
おそらく、階層数を限定したり、階層ごとに別の振舞を持ったり、もっと特殊化した構造のほうが、個別の問題領域では適切なモデルになると思う。

DDD の Specifications パターンは、Composite パターンの実装例がでているけど、個人的には、制限があっても、もうちょっとシンプルな実現方法のほうが、良いと思っています。

Flyweight パターン


Value Object の生成には、Flywieght パターンが使えるかもしれない。
でも、これは、「実装」とか「性能」の扱いの問題で、「ドメインの概念」ではない。

エバンスは、 Flyweight パターンを、「ドメイン層のモデル」の参考にはならない、「デザインパターン」のわかりやすい例だといっている。

Flyweight パターンの考え方が、ドメインモデルの参考になるシーンは、私もぱっとは思いつかない。

「デザインパターン」は「ドメインのパターン」ではない


ようするに、GoFの「デザインパターン」は、「ドメインのパターン」そのものではない、ということ。

「デザインパターン」の解説やサンプルは、どうしても「テクニカル」な側面に寄ったものが多い。

「ドメインの概念」のモデリング・設計の参考になるものもあるけど、そうでもないもの多い。
概念(考え方)を参考にした場合も、「実装」を「デザインパターン」と同じにする必然性はない。

ドメイン駆動設計に「デザインパターン」を参考にすることは、エバンスの書き方は、否定的ではないけど、「消極的」な印象です。

私も、「分析パターン」はしょっちゅう参考にしているけど、「デザインパターン」をドメイン層のモデリング・設計の参考にしたことは、ほとんど記憶にない。

自分でフレームワークぽいものを書いていたときは、デザインパターンはいろいろ参考にしていた。
最近は、ドメイン層以外は、既存のフレームワークを使っちゃう。
あるいは、ドメイン層以外の問題で、独自に書く部分は、若手の技術指向バリバリの連中が書いた部品を使うだけなんで、デザインパターンとは、疎遠になっている。

たまには、テクニカルな課題にフォーカスして、性能とことん追求で、コードを書いてみたいとか思いますけど、私自身が、実プロジェクトで、それをやることは、もうないんだろうなあ。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
     12
3456789
10111213141516
17181920212223
24252627282930
<< September 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM