modular-decomposition

モジュール分解

このスキルでは、サービスを抽出する前に パターン 1～5 の分析パイプラインを実行します。各パターンは references/ にプレーンな Markdown として保存されています。各ステップのファイルを読み込み、ユーザーのコードベースを対象に実行してください。

使用方法

クイックスタート（ユーザーが依頼できる内容）

• 全パイプライン： 「このリポジトリでモジュール分解のパターン 1～5 を実行して」「このモノリスの分割に向けて、棚卸し、結合度、ドメインのグループ分けを分析して」
• 前半のステップのみ： 「ここにあるコンポーネントを特定して規模を測って」「モジュール間で重複しているドメインロジックを見つけて」「パッケージ間の結合度を分析して」
• DDD の視点を加える： 「コンポーネントをドメインごとにグループ化して、境界づけられたコンテキストを確認して」「サービスをグループ化する前に、このコードベースに DDD の戦略的設計を適用して」

分析の後にユーザーが求めているのが 抽出順序、フェーズ、または移行ロードマップ のみであれば、代わりに decomposition-planning-roadmap を使用してください。レガシーシステムの完全な移行計画（ストラングラーフィグ、調査、複数スタック）が必要な場合は、それが主な依頼であれば legacy-migration-planner もしくはこのスキルの代わりにそちらを使用してください。

エージェントによる実行方法

1. 範囲： タスクがロードマップの作成ではなく、構造分析（棚卸し → 結合度 → グループ化）であることを確認します。不明確な場合は、全ステップを順番に実行するのか、一部のみを実行するのかを一度だけ尋ねてください。
2. 順序： パターンを 1 → 2 → 3 → 4 → 5 の順に実行します。ユーザーが明示的に範囲を限定しない限り、ステップを省略しないでください。範囲が限定された場合は、省略したパターンと、それによって後続の結論がどのように制限されるかを説明してください。
3. リファレンスの読み込み： 各パターンについて、対応する references/pattern-NN-*.md ファイルを開き、その指示に従います。簡単なチェックリストで十分な場合は、同じ番号のオプションの *-quick-reference.md を使用してください。
4. コンテキストの引き継ぎ： 先行するパターンの出力を後続のパターンで再利用します（例：パターン 1 のコンポーネント一覧をパターン 4 の結合度分析とパターン 5 のグループ化に活用します）。前のステップで特定した具体的なパス、モジュール、テーブルを参照してください。
5. ドメイン言語（パターン 5）： サブドメインや境界づけられたコンテキストを構造以外の観点から明確にする必要がある場合は、パターン 5 の前または実行中に references/domain-analysis.md を読み込みます。簡潔なルールや例を確認する場合は、オプションで references/domain-analysis-quick-reference.md または references/domain-analysis-examples.md も開いてください。
6. 成果物： パターンごとに明確で実行可能な分析結果を提示するか、結果を一つのレポートにまとめます。一般論ではなく、必ずリポジトリ内の根拠（ファイル、依存関係、メトリクス）に結び付けてください。

使用例

例 1 — 全パイプライン

User: "We're going to split this monolith—run the full decomposition analysis (Patterns 1–5)."

Agent: Execute patterns 1→5 in order, loading each references/pattern-NN-*.md, preserving outputs between steps, then summarize cross-cutting recommendations.

例 2 — 棚卸し後の結合度分析

User: "We already have a rough module list—focus on coupling (Pattern 4) and then domain grouping (Pattern 5)."

Agent: If no prior inventory exists in the thread, either run Pattern 1 briefly or derive an explicit module list from the repo before 4 and 5. State any assumptions.

例 3 — グループ化前の DDD

User: "Map bounded contexts and language, then group components into domains."

Agent: Read references/domain-analysis.md (and optional quick reference/examples) in parallel with or immediately before Pattern 5; align Pattern 5 groupings with linguistic boundaries where evidence supports it.

前提条件

• ユーザーが明示的に範囲を限定しない限り、パターン N+1 を始める前に パターン N を完了してください。後続のパターンは先行する結果に依存します（たとえば、棚卸しと構造の分析結果は結合度やグループ化の分析に役立ちます）。
• ビジネス用語、サブドメイン、境界づけられたコンテキストが不明確な場合は、パターン 5 の前または実行中に references/domain-analysis.md を使用してください（下記の「境界づけられたコンテキスト」を参照）。

順序付きワークフロー（パターン 1～5）

ステップ	パターン	主な参照資料
1	コンポーネントの特定と規模の把握	references/pattern-01-identify-and-size.md（任意：pattern-01-identify-and-size-quick-reference.md）
2	共通ドメインの検出	references/pattern-02-common-domain.md（任意：pattern-02-common-domain-quick-reference.md）
3	フラット化／階層構造	references/pattern-03-flattening.md（任意：pattern-03-flattening-quick-reference.md）
4	結合度の分析	references/pattern-04-coupling.md
5	ドメインの特定とグループ化	references/pattern-05-domain-grouping.md（任意：pattern-05-domain-grouping-quick-reference.md）

パターン 6 — 計画と抽出

パターン 6（ドメインサービスの作成／抽出）はここでは重複して説明しません。パターン 5 の後、段階的な抽出順序、マイルストーン、移行形式の計画については decomposition-planning-roadmap に切り替えてください。従来型システムの完全な移行戦略（ストラングラーフィグ、スタックをまたぐ書き換え、調査を多く要する計画）については、必要に応じて legacy-migration-planner も使用してください。

境界づけられたコンテキストと DDD の戦略的設計

• パターン 1～4 では、コードベースの各部分について、構造的な棚卸し、重複、階層、結合度に注目します。
• パターン 5 では、ソリューション空間の境界（サービスとしてどのコンポーネントをまとめるか）に沿った候補グループを作成します。
• 戦略的 DDD（サブドメイン、境界づけられたコンテキスト、ユビキタス言語）については、references/domain-analysis.md で説明しています。任意で domain-analysis-quick-reference.md と domain-analysis-examples.md も参照してください。フォルダー構造だけでなく、ビジネス用語に照らして境界を検証または調整する必要がある場合に使用してください。