DRY・SOLID・DDD…結局これ何？
プログラミング設計の考え方を一行ずつ全部まとめてみた
DRY？YAGNI？SOLID？
「なんとなく聞いたことはあるけど、ちゃんと説明できない」設計用語って多い。
この記事は、それらを一行ずつで雑に理解するためのまとめです。
プログラミングをしていると、こんな言葉をよく見かけます。
- DRY原則
- SOLID原則
- OOP（オブジェクト指向）
- DDD
- クリーンアーキテクチャ
正直なところ、
「名前は聞いたことあるけど、説明しろと言われると詰まる」
「全部ちゃんと理解しないといけない気がしてしんどい」
と思ったことがある人も多いはずです。
この記事では、解説は最低限にして、
できるだけ多くの“考え方”を「一行要約」で一覧化します。
「全部覚える」ための記事ではなく、
あとから思い出すための辞書として使ってください。
🧠 基本思想・考え方の土台
１．オブジェクト指向プログラミング（OOP）
変更の影響範囲を小さくするために、責務の持ち主を決める考え方。
２．手続き型プログラミング
処理の流れを上から順に書く、最も素直で分かりやすい書き方。
３．関数型プログラミング（FP）
状態変更や副作用を極力減らして、予測しやすくする考え方。
📐 原則・ルールとして知られている考え方
４．DRY（Don’t Repeat Yourself）
同じ「意味」を持つコードは1か所にまとめる。
５．KISS（Keep It Simple, Stupid）
賢く書くより、単純で分かるように書く。
６．YAGNI（You Aren’t Gonna Need It）
将来のための実装は、だいたい不要になる。
７．SOLID原則
変更に強いクラス設計をするための5つの指針。
🧩 SOLID原則の内訳
単一責任原則（SRP）
クラスを変更する理由は1つだけにする。
開放閉鎖原則（OCP）
既存コードを修正せずに、振る舞いを拡張できるようにする。
リスコフの置換原則（LSP）
子クラスは、親クラスとして問題なく扱える必要がある。
インターフェース分離原則（ISP）
使わない機能に依存させない。
依存関係逆転原則（DIP）
具体的な実装ではなく、抽象に依存する。
🏗 アプリケーション全体の構造に関する考え方
８．レイヤードアーキテクチャ
役割ごとに層を分けて整理する構造。
９．クリーンアーキテクチャ
ビジネスルールをフレームワークより中心に置く考え方。
１０。ヘキサゴナルアーキテクチャ
外部との接点をアダプタとして分離する構造。
１１．オニオンアーキテクチャ
依存関係は必ず内側に向ける設計。
🏷 業務やドメインを意識した考え方
１２．ドメイン駆動設計（DDD）
業務の言葉をそのままコードに落とし込むための設計思想。
１３．ユビキタス言語
チーム内で、会話とコードに同じ言葉を使うという約束。
１４．エンティティ（Entity）
同一性を持ち、時間とともに変化する概念。
１５．値オブジェクト（Value Object）
値そのものに意味があり、同一性を持たない概念。
🔁 再利用・整理のための考え方
１６．デザインパターン
よくある問題に対する、実績ある解決構造の集まり。
Strategyパターン
条件分岐を、差し替え可能な振る舞いとして表現する。
Factoryパターン
オブジェクト生成の責務をまとめて隠す。
Observerパターン
状態の変化を、通知として外部に伝える。
🧪 テストや品質に関する考え方
テスタブル設計
テストしやすい構造は、責務が分かれている構造。
単体テスト
最小単位で振る舞いを保証するテスト。
モック / スタブ
外部依存を仮の実装に置き換える仕組み。
🚧 よくあるアンチパターン
神クラス
すべての責務を抱え込んだ巨大なクラス。
if地獄
仕様追加のたびに分岐が増殖していく状態。
早すぎる抽象化
必要になる前に抽象だけを作ってしまうこと。
責務の混在
保存・計算・通知などが1か所に混ざっている状態。
🏁 最後に
これらの考え方は、
全部を最初から守るためのルール
ではありません。
困ったときに思い出すための、名前付きの引き出し
です。
「今このコード、ちょっと辛いな」と感じたときに、
この記事を開いて名前を思い出せれば、それで十分です。