抽象化

ソフトウェアの歴史は抽象化の歴史だ。適度な抽象化のおこなわれていないソフトウェアはコードの隅々まで眺めないと、そのアーキテクチャを理解できないし、メンテナンスも大変だ。

しかし、抽象化されたオブジェクトモデルやMDAの抽象化(MDA自体は疑問のあるテクノロジーだけど、その根本にある抽象化という考え方は重要)を嫌う人たちもいる。とはいえ、彼等の好むデータモデルだって、抽象化の結果だ。現実のモノがそのままモデルとして表現されているわけではない。データモデルとの違いは、抽象度のレベルだろう。多くのソフトウェアエンジニアやエンドユーザーは、データモデル的な抽象化には慣れているし、ビジネスプロセスそのものがデータモデル的な思考方法によって制限されていることも多い。

抽象的なオブジェクトモデルが嫌われるのは、抽象度が高すぎて、モデリングをおこなったり、モデルを理解できる人が少ないからだろう。たしかに、抽象的な考え方の苦手な人はいるが、全ての開発者がモデルを完全に理解できなければならないわけではない。モデリングをおこなった人しか理解できないモデルでは困るが、複数の開発者が理解できるのであれば、まったく問題はない。

オブジェクト指向が苦手で、DOAに慣れたエンジニアの多いプロジェクトで、かつ教育コストがかけられないのであれば、抽象度の低いモデルは使うという選択肢は悪くない。しかし、そのような選択が全てではない。文脈を無視して、開発者のスキルが低いからオブジェクトモデルは使えないと言い切るのは、テクノロジーの進化を無視して、現状を過剰に肯定する後ろ向きな態度じゃないだろうか。

考慮すべき事

抽象化されたオブジェクトモデルが必ずしも変更に強いとは限らない理由のひとつは、ビジネスプロセスが論理的ではなく、adhocな慣習のかたまりだということだ。しかも、ビジネスの状況の変化にあわせて、どんどんadhocなルールが追加される。抽象化は論理をベースにしているので、非論理的なルールの追加には柔軟に対応できない可能性がある。