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.