共通化を考えるとき、現在のコードが似ていることと、同じ規則に従って変わることを分けたい。共通性と可変性の分析では、全種類で守る規則と種類ごとに変えてよい部分を探すが、実装の一致だけではその境界はわからない。
たとえば画像と音声のアップロードが、どちらも「形式を検証して保存する」処理だとしても、画像の寸法制限と音声の長さ制限は別の要求で変わる。一方、同じサービスの全アップロードに適用される保存容量の制限には、共通の規則を一箇所で管理する理由がある。似た処理の全体をまとめる前に、何が共通の規則なのかを狭く特定する。
まだ同じ理由で変わると説明できない部分は、判断を保留してよい。後から一種類だけの要求が増えたとき、共通処理に種類判定や手順を省略するフラグが必要になったら、異なる規則を一つにまとめていないかを再確認する。これらは設計ミスの証明ではなく、共通化の仮説を検査する材料になる。
概念設計も現時点の理解に基づく仮説である。運用中に共通性が崩れるのは、当初の理解不足だけでなく要件の変化によっても起こる。共通処理を維持するための例外が増え続けるなら、独立した実装へ戻してから共通部分を探し直す余地を残したい。
https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction