汎化の捌き方

SDP

Javaプログラミングにおけるextendsやimplementsの使い方は、それなりの難しさはあるものの、プログラムを動かすという狙いがはっきりしているだけに、わりと扱いやすい。
一方、ドメイン分析における汎化(generalization)は扱いが難しい。
汎化そのものは「is-a」の関係、集合とその部分集合というように考えれば、モデルの中でいくらでも使う場所が出てくる。しかしながら、汎化を無軌道に乱発すると、後々困ったことになるのである。
不必要にモデルが複雑化するという"分析中毒(analysis paralysis)"という問題もあるけれど、さらに深刻なのは設計・実装の段階で実装モデルにうまくマッピングができず、分析モデルと実装モデルに乖離が出てきてしまうことである。こうなると、正本は実装モデル上にしかないという状況となり、分析から設計、実装まで抽象度の異なった同一モデルを共有することによって、反復的・漸進的開発を可能とするOOA/Dの理念から乖離していしまうのである。
汎化と実装モデルの相性の悪さは、以下の2点に集約される。

前者は、多重継承の問題、後者はそもそも継承という概念が用意されていない、という問題であり、どちらの場合も、ドメイン・モデルで無秩序に汎化を多用されると困ってしまう。

実装的な観点で汎化(あるいは継承)が必要となるのは、実装の再利用をしたい場合とポリモーフィズムを使いたい場合である。実装の再利用目的の継承はできるだけ避ける、というのが経験則となっているので、ここでは触れない。問題はポリモーフィズムである。

オブジェクト原理主義によるドメイン・モデルでは、ドメイン・モデルに対して直接アプリケーションの責務を割り当てる。このため、ドメイン・モデル上でポリモーフィズムが必要となり、汎化を使う必然性が出てくる。
一方、現代的なモデリングによってアプリケーション層とドメイン層を導入するのであれば、アプリケーションの責務の多くはアプリケーション層のオブジェクトに割り振られることになるので、ドメイン層への責務の割当は抑止されることになり、つまるところポリモーフィズムを必要とする場所がなくなり、結果として汎化を使う必然性がなくなることになる。

このように考えていくと、ドメイン分析において汎化を使う必要性をかなり排除することができるのではないかという点に思い至る。もちろん、"「is-a」の関係、集合とその部分集合"は汎化を使った方が分かりやすいモデルになることも多いのだけれど、前述したように設計・実装とずれてしまうとモデルが死んでしまうのであり、それを避けるためにあえて汎化を使わないで済ます、というアプローチが実務的にはかなり重要になってくると思われるのである。

あるいは、実装を視野に入れて汎化を注意深く使う、といった方がよいかもしれない。

そのような観点から、ドメイン分析の手法についてつらつら考えているところである。ユースケースもかなり難しい技術だけれど、ドメイン・モデルも一筋縄ではいかない。