package-design

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

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

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

將混亂的程式碼庫重新設計為清晰的套件/模組結構的指南。目標：(1) 重新組織混亂的程式碼，(2) 分割單一巨大模組，(3) 檢查套件邊界，(4) 為新專案設計模組層次結構。由结构改进请求触发，例如“我们想要检查包结构”、“模块依赖关系太复杂”、“我们需要重新组织文件布局”或“我们想要消除循环依赖关系”。 來源：j5ik2o/okite-ai。