オブジェクト指向設計を保守しやすく拡張しやすく保つための 5 つの基本原則。Robert C. Martin（Uncle Bob）が体系化した。
5 つの原則
| 略 | 名称 | 一言で |
|---|---|---|
| S | Single Responsibility（単一責任） | 1 つのクラスに変更理由は 1 つだけ |
| O | Open/Closed（開放閉鎖） | 拡張に開き、修正に閉じる |
| L | Liskov Substitution（リスコフ置換） | サブクラスは親クラスと置き換えても破綻しない |
| I | Interface Segregation（インターフェース分離） | 使わないメソッドに依存させない |
| D | Dependency Inversion（依存性逆転） | 上位は下位ではなく抽象に依存する |
各原則の典型違反
| 原則 | 違反例 | 是正方針 |
|---|---|---|
| SRP | OrderService が在庫引当・決済・通知を全部抱える | 責務ごとにクラス分割 |
| OCP | 商品種別が増えるたびに if/switch を追記 | ポリモーフィズムで拡張点を作る |
| LSP | Square extends Rectangle で setWidth の意味が壊れる | 継承ではなく合成へ |
| ISP | 巨大インターフェースを実装側で空メソッド化 | 用途別に小さく分割 |
| DIP | ドメイン層が直接 ORM を呼ぶ | リポジトリインターフェース経由にする |
DDD との関係
SOLID は DDD（ドメイン駆動設計）を支える設計原則として機能する。特に DIP（依存性逆転） はドメイン層を技術詳細から守る要であり、リポジトリパターン・ヘキサゴナルアーキテクチャの根拠になる。
AI 駆動開発での意義
AI が生成するコードは「動くこと」を優先するため、SRP / OCP に違反した「肥大化したクラス」「if 分岐の積み重ね」が出やすい。レビュー時に SOLID をチェックリストとして使うと、生成コードの構造的な腐敗を早期に発見できる。
マルチモール EC での適用イメージ
CTS-EC 共通商品マスタでは、共通マスタ層でカラー・サイズ・ブランドを一度だけ正規化し、モールごとの変換ルールを差し替える構造をとっている。これは OCP（モール追加時に共通マスタ側を改修しない） と SRP（正規化責務とモール変換責務を分離） の素直な適用例。AI に「新しいモールを追加して」と指示する際も、変更影響が変換層に閉じるためレビュー範囲を絞り込める。
関連記事
- 開発手法ガイド：概要 — SOLID を含む設計原則の積み上げ順序
- COBOL × DDD 設計パターン — SOLID をレガシー言語に適用する例
- CTS-EC 共通商品マスタ — OCP / SRP がモール追加コスト削減に直結する実例
関連用語
- オブジェクト指向 — SOLID が前提とするパラダイム
- DDD — SOLID を実装指針として活用する設計手法
- RDD（責務駆動設計） — SRP の出発点となる責務分析手法
- リポジトリパターン — DIP の代表的な適用例
- ヘキサゴナルアーキテクチャ — DIP をアーキテクチャ全体に適用した形
- クリーンアーキテクチャ — DIP を中核に据えた整理
- SoC（関心の分離） — SOLID の上位概念にあたる設計原則
- DRY — SOLID と並ぶ基本原則