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。