【84】フレームワークは相性で選べ

　システムの基礎としてソフトウェア・フレームワークを選ぶときには、フレームワーク単独の品質や機能だけではなく、システムを構成するフレームワークセットがどの程度うまく連携するか、システムの発展にともなって新しいソフトウェアを追加しなければならなくなったときに、それをどの程度うまく吸収できるかを考えなければなりません。つまり、互いに重複がなく、それぞれが控えめで、単純で、何かに特化したフレームワークを選ぶということです。

　個々のフレームワークやサードパーティー・ライブラリは、別個の論理ドメインや問題を扱い、あなたが使いたいと思っている他のフレームワークのドメインや問題を荒らさないことが大切なのです。

　採用しようとしているフレームワークの論理ドメインや問題がどのくらい重なり合っているかをきちんと把握しなければなりません。必要ならベン図を描いてみることです。ドメインが大きく重なる 2 つのデータモデルや、非常に近い問題を別々の方法で解決する 2 つの実装は、不必要にシステムを複雑にします。概念化や表現のわずかな違いを、その場しのぎのグルーコードでマッピングしたりパッチしたりしなければならなくなります。こうなるとグルーコードが複雑になるだけでなく、2 つのフレームワークの最大公約数的な機能しか使えなくなる可能性が高くなります。

　フレームワークの重なり合う部分を小さくするには、システムの要件という制約のもとで有用性‐傲慢率が低いフレームワークを選ぶことです。「有用性」とは、あなたのプロジェクトが必要とするフレームワーク内の機能やデータ表現のことで、これが分子になります。「傲慢度」とは、フレームワークが世界に対してどのくらい「オレだけ」的「何でもコイ」的「それはオレの役目だ」的考え方をしているかで、これが分母になります。そのフレームワークは、データの表現と制御の併用を要求していますか？　データモデルやパッケージ / クラスセットは、システムが必要とする以上のものになっていますか？　フレームワークの原理主義者にならなければならず、他のフレームワークは同じ教派に属するものだけに限られてしまいますか？

　フレームワークが思い切り傲慢なら、プロジェクトの機能価値の 75% くらいは提供してもらいたいところです。

　システムは、それぞれのドメインを定全に支配しつつ、単純で、従えめで、柔軟性の高い相互に排他的なフレームワークを使って構成すべきです。