既存のドメインとの整合性を保ち、継承や抽象化の設計が妥当か？¶
Type: Structure
Category: ドメイン
Audience: 設計初心者 / 設計中のチーム / レビュワー
背景・概要¶
既存のドメインと齟齬があるモデルを導入すると、一貫性の破綻や二重管理が発生しやすく保守性・可読性が大きく低下する
また、安易な継承や抽象化の導入は構造を複雑化させ、将来的な機能追加・修正コストを高める要因にもなりうる
例¶
- UserやDocumentなどの共通エンティティを車輪の再発明せず、既存コードベースから利用する
- Task → ScheduledTaskのように、明確な振る舞いの違いがある場合に限って継承を使う
- sealed Interfaceやsealed classなどを活用し、ドメインの制約(状態や役割の限定)をコンパイル時に保証する
よくある失敗例¶
- 同名のクラスが複数箇所で独自定義されており、意味・振る舞いが微妙に異なる
- 継承元に依存したビジネスロジックが拡散し、変更時に副作用を引き起こす
- 「将来使いそうだから抽象化した」が結局使われず、過剰設計になっている
FAQ¶
Q. 継承と委譲はどちらを使うべき？
A. 振る舞いの再利用が主目的なら低コストな委譲が望ましく、普段の開発では委譲をメインにすべき。継承は共通ライブラリの開発などでよく使われるが、型階層の設計が明確かつ中長期的に変化がない場合に限定すべきで、普段の実務ではあまり使わないのが無難
Q. 新たなエンティティを追加する場合、どこまで既存と揃えるべき？
A. 命名・制約・状態などを既存設計の意図と照らして整合性を保つ。安易なモデル分離は避けるのが無難