package-design

| 機能（feature/vertical） | 変更が縦に閉じる | チーム独立、マイクロサービス候補 | 共通化地獄 | | ドメイン（業務概念） | 情報的凝集 | ドメインモデルの一貫性重視 | コンテキスト間翻訳コスト | | レイヤ（技術層） | 技術責務の分離 | 小規模、導入初期 | 1変更が全層に散る | | 責務（変更理由） | CCP準拠 | 変更頻度が明確 | 初期分析コスト | | API境界（公開IF） | 表面積最小化 | ライブラリ設計 | 内部柔軟性とのバランス |

MECEは「設計の目的」ではなく「網羅性チェックの補助」として使う。 厳密MECEにこだわりすぎると、横断的関心（ログ、認可、トランザクション等）の扱いで境界が薄くなる危険がある。8〜9割の網羅で十分。

良い例: authentication, billing, inventory 避ける例: utils, helpers, common, misc

Richtlinien für die Neugestaltung einer unübersichtlichen Codebasis in eine klare Paket-/Modulstruktur. Ziele: (1) unordentlichen Code neu organisieren, (2) ein einzelnes großes Modul aufteilen, (3) Paketgrenzen überprüfen, (4) Modulhierarchie für neue Projekte entwerfen. Ausgelöst durch Strukturverbesserungsanfragen wie „Ich möchte die Paketstruktur überprüfen“, „Modulabhängigkeiten sind zu komplex“, „Ich möchte die Dateiplatzierung aufräumen“ oder „Ich möchte zirkuläre Abhängigkeiten beseitigen“. Quelle: j5ik2o/okite-ai.