これまでの十四章
順応者
顧客/供給者の開発チームがうまくいかないケース
- 供給者にとって顧客のビジネスが重要でない場合
- 供給者が多くの顧客を抱えている
- 昔からの顧客に市場の方向性が変わったため価値が見いだせない
- 供給者の経営がうまくいっていない
- ビジネスから撤退した
- ・・・
- 上流に下流チームの要求に応える動機がない場合
こんな場合、供給者に期待をせず、なんとかするしかない・・・という怖いパターンです。
３つの選択肢
①. 上流の機能を使用することを一切断念する
これが可能である場合、**別々の道パターン(次回以降読むところ)**を選択することになります。
②. 下流チームは独自のモデルを開発し、上流との接続には変換層を用意する
この場合は、**腐敗防止層(次回読むところ)**を使用することになります。
これを選択する動機としては、上流のモデルを下流で扱うのが困難な場合です。カプセル化の欠如・ぎこちない抽象・設計を扱うのが難しい場合にこのパターンを採用することになるでしょう。
③. 順応者
上流の設計・品質が悪くない場合、下流では独立したモデルを(ある意味積極的に)断念して、上流のモデルをそのまま利用するパターンです。
もちろん心情的には、魅力的でもないし、受け入れがたい選択肢でもありますし、実際このパターンを選択されない事の方が多いかもしれません。
しかし、このパターンの良いところは、コンテキスト境界間の複雑な変換がなくなること。統合も簡略化されること、ユビキタス言語も共有できることです。
これにより下流も意外と良い設計とつながる可能性もあります。
上流が全く対応してくれそうにないけど、どうしても連携が必要で、かつ上流のモデルがそんなに悪いものではない場合に、選択肢の一つとして一度は考えて見るべきでしょう。
そういう意味で、このパターンが言語化され、ここで解説されていることには大変意義のあることだなと思うわけです。