From ddd-skills
既存コードを DDD へ段階的にリファクタリングする戦略立案と実行を支援する。 次のような依頼があったときに使う:「DDDにリファクタリングする」「レガシーコードをDDD化する」 「貧血ドメインモデルを改善する」「トランザクションスクリプトから脱却する」 「段階的にDDDを導入する」「ドメインモデルを豊かにする」「アンチパターンを修正する」 「ドメインロジックをエンティティに移動する」。 または、DDD移行、貧血ドメインモデルの解消、Strangler Fig、段階的リファクタリングに言及する場合にも使う。
How this skill is triggered — by the user, by Claude, or both
Slash command
/ddd-skills:ddd-refactoring [対象のコードやモジュールの説明][対象のコードやモジュールの説明]This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
既存コード(貧血ドメインモデル・トランザクションスクリプト・レイヤー混在)を DDD へ段階的にリファクタリングする戦略立案と実行を支援する。
既存コード(貧血ドメインモデル・トランザクションスクリプト・レイヤー混在)を DDD へ段階的にリファクタリングする戦略立案と実行を支援する。
位置づけ: anti-pattern-detector エージェントが問題を検出し、本スキルが修正を導く。リファクタリング前にまず anti-pattern-detector で現状を把握することを推奨する。
どの戦略で進めるか?
│
├─ 対象が小さい(数クラス〜1モジュール)
│ └→ 直接リファクタリング(後述のロードマップを順に適用)
│
├─ 対象が大きいが、モジュール境界が明確
│ └→ モジュール単位の段階的リファクタリング
│ (重要度の高いモジュールから1つずつ)
│
├─ 対象が大きく、境界も不明確(巨大な泥団子)
│ └→ Strangler Fig パターン
│ (新しいモデルを隣に作り、徐々に置き換える)
│
└─ 書き直しの誘惑がある
└→ 原則避ける。全面書き直しは仕様の暗黙知を失う
リスクの小さい順に適用する。各ステップは独立して価値があり、途中で止めても改善が残る。
コードを変更する前に、ドメインの言葉を整理する(ubiquitous-language スキルを参照)。
プリミティブ型をドメインの型に置き換える(value-object スキルを参照)。
Money)を導入し、利用箇所を段階的に置き換えるサービスクラスに漏れたビジネスロジックをエンティティ・VO に移す(entity-design / domain-service スキルを参照)。
手順:
1. サービスのメソッドから「主語が特定のエンティティ」のロジックを特定する
2. エンティティに新メソッドを追加し、サービスから委譲する(旧メソッドは残す)
3. テストが通ることを確認する
4. 呼び出し元を新メソッドに切り替え、旧メソッドを削除する
5. 公開セッターを1つずつ削除し、ビジネスメソッドに置き換える
トランザクション境界と整合性の単位を定義する(aggregate-design スキルを参照)。
ドメイン層からインフラ依存を排除する(domain-classifier / architecture-checker を参照)。
集約をまたぐ処理を結果整合性に分離する(domain-event スキルを参照)。
anti-pattern-detector の検出結果に対応する修正手順:
| アンチパターン | 修正レシピ | 適用ステップ |
|---|---|---|
| Anemic Domain Model | ロジックをサービスからエンティティへ段階的に移動 | Step 3 |
| Repository per Entity | 集約ルートを特定し、子のリポジトリを統合 | Step 4 |
| Leaking Infrastructure | ポート定義とマッピング層の導入でインフラ依存を分離 | Step 5 |
| God Aggregate | 不変条件の分析に基づき集約を分割、参照を ID 化 | Step 4 |
| Skipping Ports | アプリケーションサービスを導入し呼び出し経路を是正 | Step 5 |
| CRUD Thinking | ユビキタス言語によるメソッドの再命名から着手 | Step 1, 3 |
| Premature CQRS | 複雑性に見合わない分離を統合し単純化 | 個別判断 |
| Cross-Aggregate Transaction | ドメインイベントによる結果整合性へ分離 | Step 6 |
巨大で境界の不明確なレガシーに対しては、新モデルを隣に育てて置き換える。
1. 境界を定める
新しいモデルを適用する範囲(コンテキスト)を決める
(bounded-context スキルを参照)
2. ファサード/腐敗防止層を置く
レガシーと新モデルの間に変換層を設け、
新モデルがレガシーの構造に汚染されないようにする
3. 新規機能・変更箇所から新モデルに実装する
既存機能は動かしたまま、入口で新旧に振り分ける
4. レガシー側の利用を計測し、ゼロになった部分を削除する
各ステップの完了時に確認する:
examples/ ディレクトリに具体例がある:
examples/refactoring-example.pseudo — 貧血モデル+トランザクションスクリプトを段階的に改善する Before/Afternpx claudepluginhub dskst/ddd-skills --plugin ddd-skillsCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.