package-design

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

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

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

Lignes directrices pour repenser une base de code désordonnée en une structure claire de package/module. Objectifs : (1) réorganiser le code désordonné, (2) diviser un seul module énorme, (3) revoir les limites des packages, (4) concevoir la hiérarchie des modules pour les nouveaux projets. Déclenché par des demandes d'amélioration structurelle telles que « Je souhaite revoir la structure du package », « Les dépendances des modules sont trop complexes », « Je souhaite ranger le placement des fichiers » ou « Je souhaite éliminer les dépendances circulaires ». Source : j5ik2o/okite-ai.