はじめに
アーキテクチャの世界では「ポリシー（Policy）」と「レベル（Level）」という考え方が重要です。
これらは単なる抽象的な概念ではなく、システムをどの層に配置すべきかを決める指標 になります。
ポリシー（Policy）とは
- システムのルールや振る舞いを定めるもの
- ビジネスルール、ユースケース、ドメインロジックが該当
- 長期的に変わらず、システムの「心臓部」となる部分
例：
- 「会員登録にはメールアドレスが必須」
- 「注文金額が1万円を超える場合は送料無料」
レベル（Level）とは
- 抽象度の高さ・低さを表す概念
- 抽象度が高いほど「方針（Policy）」に近い
- 抽象度が低いほど「実装（Details）」に近い
レベルの軸
- 高レベル（High Level）: ビジネスルールや方針 → 抽象的で長生き
- 低レベル（Low Level）: DB操作やUI制御 → 具体的で変わりやすい
Policy と Level の関係
Robert C. Martin の「Clean Architecture」では以下の原則が示されています。
- 高レベルポリシーは低レベルの詳細に依存してはいけない
- 依存関係は必ず 低レベル → 高レベル に流れるべき
- 高レベル（Policy） は長期的に不変
- 低レベル（Details） は技術や環境によって頻繁に変わる
- レベルを意識して依存方向を設計することで、変更耐性を高められる
実例で見る Policy と Level
例1：ユーザー認証
-
Policy（高レベル）
「ユーザーはメールアドレスとパスワードで認証する必要がある」 -
Details（低レベル）
- 認証手段：JWT、OAuth、セッションID
- データストア：MySQL、PostgreSQL、Firebase
認証方式やDBは変わり得るが、「認証の必要性」というポリシーは変わらない。
例2：ECサイトの注文処理
-
Policy（高レベル）
「商品を注文すると在庫が減る」 -
Details（低レベル）
- UIはReactかFlutterか
- 在庫管理はRDBかNoSQLか
技術選択は将来的に変わるが、注文ルールは長期的に不変。
まとめ
- ポリシー（Policy） = システムを支配するルール
- レベル（Level） = 抽象化の高さを示す
- 高レベル（不変）を低レベル（可変）から守る のがアーキテクチャの役割
良いアーキテクチャとは、変わりやすいもの（技術詳細）から変わりにくいもの（ビジネスルール）を守る設計 です。