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。