package-design

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

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

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

Directrices para rediseñar una base de código desordenada en una estructura clara de paquete/módulo. Objetivos: (1) reorganizar código enredado, (2) dividir un único módulo enorme, (3) revisar los límites del paquete, (4) diseñar jerarquías de módulos para nuevos proyectos. Activado por solicitudes de mejora estructural como "Quiero revisar la estructura del paquete", "las dependencias de los módulos son demasiado complejas", "Quiero ordenar la ubicación de los archivos" o "Quiero eliminar las dependencias circulares". Fuente: j5ik2o/okite-ai.