REP — Reuse-Release Equivalence Principle（再利用・リリース等価の原則）
- 再利用の最小単位＝リリース単位（＝パッケージ）。バージョン管理で配布できる単位にまとめる。(A Memorandum)
- 書籍の正誤表でも用語表記が補足されています（Equivalence の綴りなど）。(gihyo.jp)
実務ヒント：社内ライブラリは「タグを切れる塊」で配る。README・CHANGELOG・セマンティックバージョニング必須。
CRP — Common Reuse Principle（共通再利用の原則）
-
一緒に再利用されるものだけを同じパッケージへ。使わない依存を抱え込まない。(blog.avenuecode.com, Zenn)
実務ヒント：UIコンポーネントとHTTPクライアントを同梱しない。利用側に“要らない副作用”を持ち込まない。
CCP — Common Closure Principle（共通閉鎖の原則）
-
同じ変更理由で変わるものは同じパッケージに入れて、影響範囲を局所化する。(A Memorandum, Zenn)
実務ヒント：「請求書の仕様変更」は“請求”パッケージだけの差し替えで済む構造を目指す。
ADP — Acyclic Dependencies Principle（非環式依存の原則）
- 循環依存は禁止。循環があると単独リリースやテストができない。(A Memorandum)
- 断ち切り方：新パッケージ抽出／DIP・ISPで依存反転。(Academia)
実務ヒント：依存グラフをCIで可視化してサイクル検知を落とす。
SDP — Stable Dependencies Principle（安定依存の原則）
- 依存は“より安定な方向”へ（多くに依存され・自分はあまり依存しない側）。(A Memorandum)
- 安定度の指標に Fan-in/Fan-out を用いる考え方も有効。(takatechskill.com)
実務ヒント：ドメインの核（抽象）は外縁（UI/Infra）に依存しない。外縁→内側へ一方向。
SAP — Stable Abstractions Principle（安定抽象の原則）
- 安定なパッケージほど抽象的に。不安定なパッケージは具象でOK。(A Memorandum)
- 「安定＝変更しづらい」を抽象で拡張可能に保つ。(Qiita, takatechskill.com)
実務ヒント：安定側に抽象（インターフェース）を置き、実装は不安定側へ追い出す。
SOLID 原則（5）
SRP — Single Responsibility Principle（単一責任の原則）
- モジュールは**ひとつの“変更理由（アクター）”**だけに責任を持つ。(ogis-ri.co.jp, Zenn)
実務ヒント：保存・集計・通知を1クラスに詰めない。責務でクラス分割。
OCP — Open-Closed Principle（開放閉鎖の原則）
-
拡張に開き、修正に閉じる。抽象化＋ポリモーフィズムで差し替え可能に。(Zenn)
実務ヒント：戦略パターン／プラグイン・DIで“追加”対応。既存コードに手を入れない。
LSP — Liskov Substitution Principle（リスコフの置換原則）
-
上位型を下位型で置き換えても振る舞いが保たれること。事前条件≦・事後条件≧・不変維持など。(Qiita)
実務ヒント：サブクラスで例外を増やさない・契約を弱めない。テストは“親の仕様”で通す。
ISP — Interface Segregation Principle（インターフェース分離の原則）
DIP — Dependency Inversion Principle（依存性逆転の原則）
まとめ（運用チートシート）
- パッケージは“変更理由”と“再利用単位”で切る（CCP×CRP×REP）。循環はゼロ（ADP）。(A Memorandum, blog.avenuecode.com)
- 依存は安定かつ抽象へ（SDP×SAP）。抽象は内側、実装は外側。(A Memorandum)
- SOLIDでクラス設計を固め、パッケージ原則で“差し替え・再配布・影響局所化”を実現。
参考（抜粋）
- 各パッケージ原則の和訳・要点（mammbブログ）(A Memorandum)
- ちょうぜつ本の正誤表（技術評論社）(gihyo.jp)
- まとまった解説（Zenn / Qiita）(Zenn, Qiita)
- SOLIDの各論（SRP / LSP / ISP / DIP）(ogis-ri.co.jp, Qiita, ウィキペディア)