もし、アナリシスパターンに精通していたとしても、プロジェクト固有の要求に答える事は困難である。しかし探求に有益な指針を、そして抽象的な用語を与えてくれる。
これら全ては知識の咀嚼、深い洞察に対するリファクタリングに活力を与え、開発者を刺激する。
よく知られているアナリシスパターンの用語を使う場合、避けるべき1つの変更がある。
即ち(見かけ上は変更が多くても、基本的なコンセプトはいじるなという事である。
(モデル定義が自然と変更されるならば、名前の変更も避けたほうが良い)
これには2つの理由がある
ある業種のあるアプリケーションに特化した、あるい汎用化されたオブジェクトモデルが数多く作成されてきたが、これらを適用するだけでは、モデル選択までの過程や、それに続く結末までを知る事は殆どできない。
この部分は分析では最も有益な部分であるのに。
あるドメイン用のパターンは他の多くの分野のアプリケーションにも広く共有できるものだ。
整理された知識によるreapplicationはフレームワークやコンポーネントを通したコードの再利用の試みとは全く異なるものである。
分析はモデルの断片でしかないが、アナリシスパターンは最も重要で、難しい部分の判断や代変案への気付きに注力している。
理解が難しい(=> 共有が難しい)と言われるアナリシスパターンがUBIQUITOUS LANGUAGEや開発者に活力を与えてくれるとは思えない。