菜单
DDD ドメインモデル設計と Mermaid 出力（設計モード）、既存コードからの DDD モデル抽出・評価（逆引きモード）の2モードを持つ。「ドメインモデルを設計して」「DDDで設計して」「集約を設計して」などで設計モード発動。「既存コードからモデルを抽出して」「リバースエンジニアリングして」などで逆引きモード発動。設計モードでは、Step 1 の知識構造化フェーズ（業務知識・判断ルール・用語の揺れの整理）を原則実行してからモデリングに入る。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/ynitto/sandbox --skill domain-modeler命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | domain-modeler |
| description | DDD ドメインモデル設計と Mermaid 出力（設計モード）、既存コードからの DDD モデル抽出・評価（逆引きモード）の2モードを持つ。「ドメインモデルを設計して」「DDDで設計して」「集約を設計して」などで設計モード発動。「既存コードからモデルを抽出して」「リバースエンジニアリングして」などで逆引きモード発動。設計モードでは、Step 1 の知識構造化フェーズ（業務知識・判断ルール・用語の揺れの整理）を原則実行してからモデリングに入る。 |
| metadata | {"version":"2.0.0","tier":"experimental","category":"design","tags":["ddd","mermaid","entity","aggregate","reverse-engineering"]} |
DDD（Domain-Driven Design）に基づいてドメインモデルを設計し、Mermaid classDiagram として出力するスキル。
2つのモードを持つ:
| モード | 方向 | 用途 |
|---|---|---|
| 設計モード | ドメイン知識 → Mermaid 図 | 新規システム・ドメイン再設計 |
| 逆引きモード | 既存コード → Mermaid 図 + DDD 評価 | リファクタ計画・技術負債可視化 |
ユーザーの依頼を確認:
コード/ファイル/ディレクトリを指定している？
YES → 逆引きモード（Reverse Engineering Mode）へ
NO → 「設計からですか？既存コードからですか？」と確認
既存コードに言及している（「解析」「抽出」「既存」「実装から」）？
YES → 逆引きモード（Reverse Engineering Mode）へ
NO → 設計モード（Design Mode）へ
Step 1: 知識構造化 ← 業務知識・用語の揺れ・判断ルールの整理（原則実行）
Step 2: ドメイン理解 ← ビジネスドメイン・ユースケース・ユビキタス言語の確定
Step 3: 戦略的設計 ← Bounded Context・Context Map
Step 4: 戦術的設計 ← Entity / Value Object / Aggregate
Step 5: ドメインサービス特定 ← Entity/VOに収まらない操作
Step 6: ドメインイベント設計 ← 集約間通信・副作用
Step 7: 図として表現 ← Mermaid classDiagram
設計モードに入ったら原則このフェーズから始める。 業務知識・判断ルール・用語の揺れを整理し、Step 2（ドメイン理解）への入力を作る。
スキップ条件（以下なら Step 2 へ直行）:
ユーザーへの問いかけで業務記述・用語・判断ルールを収集する:
収集した用語の同義語・揺れ・コンテキスト別意味を整理し、ユーザーに確認する:
| 用語 | 同義語・揺れ | 文脈 | 仮の定義 | 要確認 |
|---|---|---|---|---|
| 注文 | 受注、オーダー | 販売側 | 顧客が購入を確定した申し込み | — |
| 注文 | 発注 | 仕入側 | 仕入先への購入依頼 | 別概念として分離が必要か |
揺れの分類:
「〜の場合は〜する」「〜でなければならない」型のルールを構造化する:
ルールID: R-001
条件 : 在庫数 = 0
アクション: 注文受付を拒否する
例外 : 予約注文フラグが立っている場合は受け付ける
強制力 : 必須（違反不可）
不変条件・状態遷移ルール・認可ルール・計算ルールを区別して抽出する。
整理した用語とルールから Bounded Context の候補を仮決定する:
「同じ言葉が異なるチーム・業務プロセスで異なる意味を持つか？」
YES → 別の概念境界候補
NO → 同じ境界内で統一可能
境界候補をマップとして表現し、ユーザーに確認する。
Step K1〜K4 を元に語彙表を作成し、Step 1 への入力とする:
| 用語 | 定義 | 文脈 | 除外する言い方 |
|---|---|---|---|
| 注文 | 顧客が確定した購入申し込み | 販売 | 「受注」は使わない |
詳細ガイド → references/domain-knowledge-structurer.md
Step 1 で作成したユビキタス言語草案と概念境界を元に、以下を確定する:
Step 1 をスキップした場合は、ユーザーの説明からドメイン語彙を抽出する:
| 抽出元 | 候補の種類 |
|---|---|
| 名詞 | Entity / Value Object / Aggregate |
| 動詞・出来事 | Domain Event / Domain Service |
| 「〜は〜でなければならない」 | 不変条件（Invariant） |
原則: ドメインエキスパートが使う言葉をそのまま使う。技術用語（UserRecord、OrderDTO など）に翻訳しない。
ユビキタス言語の更新: ユースケースの説明から新たな用語が出てきた場合、草案に追記する。
Bounded Context と Context Map を設計する:
ユビキタス言語の更新: 同名異義語（コンテキスト別に意味が変わる用語）が確定した場合、語彙表の「文脈」列にコンテキスト名を明記して分離する。
詳細 → references/bounded-context.md
各候補を以下の基準で分類し、表形式でユーザーに確認を取る:
| クラス名 | 分類 | 理由 |
|---|---|---|
| Order | Aggregate Root | 注文ライフサイクル全体を管理、外部から参照される |
| OrderItem | Entity | 注文内で ItemId で識別される |
| Money | Value Object | 金額+通貨の組み合わせで定義、不変 |
| Address | Value Object | 配送先は属性値で識別、交換可能 |
各クラス間の関係を決める際に確認すること:
*-- vs 関連 -->）ユビキタス言語との照合・更新:
Flag、Type、Info など）が使われていたら業務用語に置き換える詳細 → references/core-concepts.md / references/aggregate-design.md / references/relationships.md
以下の場合に Domain Service を設計する:
ユビキタス言語との照合・更新: サービス名・ポリシー名はドメインエキスパートが使う動詞・業務名から命名する。新しいサービス概念が確定したら語彙表に追加する。
以下の場合に Domain Event を設計する:
ユビキタス言語との照合・更新: イベント名はドメインエキスパートが使う過去形の業務動詞で命名する（OrderPlaced、PaymentConfirmed など）。確定したイベント名は語彙表に追加する。
詳細 → references/domain-events.md
以下の規則に従って図を出力する。
<<Aggregate Root>> 集約ルート
<<Entity>> 集約内エンティティ
<<Value Object>> 値オブジェクト
<<Domain Event>> ドメインイベント
<<Domain Service>> ドメインサービス
| 記号 | 種別 | 用途 |
|---|---|---|
A "1" *-- "1..*" B | コンポジション | 集約内のエンティティ（ライフサイクル共有） |
A o-- B | 集約 | 参照するが独立したライフサイクルを持つ |
A --> B | 関連 | 方向付き参照（A が B を知っている） |
A ..> B | 依存 | イベント発行・一時的な使用 |
A <|-- B | 継承 | B が A の is-a 関係 |
含める:
status、totalAmount など）place()、cancel() など）%% ── Aggregate: Order ──）含めない:
createdAt / updatedAt などの監査フィールド@Column、DB の型など）classDiagram
%% ── Aggregate: Order ──
class Order {
<<Aggregate Root>>
+OrderId id
+CustomerId customerId
+Money totalAmount
+OrderStatus status
+place() void
+cancel() void
}
class OrderItem {
<<Entity>>
+OrderItemId id
+ProductId productId
+Quantity quantity
+Money unitPrice
+subtotal() Money
}
class Money {
<<Value Object>>
+Decimal amount
+Currency currency
+add(Money) Money
}
class OrderStatus {
<<Value Object>>
PLACED
CONFIRMED
SHIPPED
CANCELLED
}
class OrderPlaced {
<<Domain Event>>
+OrderId orderId
+DateTime occurredAt
}
Order "1" *-- "1..*" OrderItem : contains
OrderItem *-- Money : unitPrice
Order *-- Money : totalAmount
Order *-- OrderStatus : status
Order ..> OrderPlaced : raises
図をユーザーに提示し、以下を確認する:
Mermaid 記法の詳細 → references/mermaid-notation.md
既存コードからドメインモデルを抽出し、DDD 観点で評価・改善提案を行う。
詳細 → references/reverse-engineering.md
Step R1: コード収集 ← 対象ファイル・ディレクトリを特定
Step R2: 要素抽出 ← クラス・フィールド・メソッド・依存関係を解析
Step R3: DDD 分類 ← Entity / Value Object / Service / Repository を識別
Step R4: 集約境界の推定 ← ライフサイクル・不変条件・トランザクション境界を推定
Step R5: Mermaid 図生成 ← 現状の構造を As-Is 図として出力
Step R6: DDD ギャップ評価 ← 問題点を列挙し To-Be 改善案を提示
対象を確認する:
src/domain, src/model, src/entity, domain/, models/ などを探索する読み込む優先順位:
domain/, model/, entity/ フォルダ配下（ドメイン層が明確な場合）*Entity.ts, *Model.py, *Aggregate.java, *VO.* などsrc/ 全体を走査してクラス定義を収集各ファイルからクラス名・フィールド・メソッド・アノテーション・継承/実装関係・依存関係を抽出する。 言語別の識別パターン（TypeScript / Java / Python / Go / C# / Ruby）→ references/reverse-engineering.md
抽出した要素を分類する（判定困難な場合は「不明」として記載しユーザーに確認）:
| 分類 | 主な手がかり |
|---|---|
| Entity | ID フィールドあり・状態変化メソッドあり・@Entity など |
| Value Object | ID なし・全フィールド不変・equals() が値比較 |
| Aggregate Root | Repository が対応存在・最も多くのビジネスメソッドを持つ |
| Domain Service | ステートレス・複数集約をまたぐ・*Service/*Policy 命名 |
| Repository | findById()/save() メソッド・*Repository/*Dao 命名 |
@Transactional / 同一 Repository で save されるオブジェクト群現状のコード構造をそのまま図にする（DDD 的に正しくなくても現実を反映する）。
DDD 上の問題点は ⚠️ コメントとして図内に記載する:
classDiagram
%% ⚠️ As-Is: 現状のコード構造（DDD 評価前）
class Order {
<<Aggregate Root?>>
+String id
+place() void
}
class Customer {
<<Entity?>>
+String id
}
Order --> Customer : references directly ⚠️
チェック項目（集約境界・参照形式・Entity/VO 正確さ・貧血モデル・Repository 配置・ユビキタス言語）→ references/reverse-engineering.md
出力形式:
## As-Is ドメインモデル図
[Mermaid classDiagram - 現状]
## DDD ギャップ評価
| # | 問題 | 該当 | 深刻度 | 改善方針 |
|---|------|------|--------|---------|
| 1 | 集約間の直接オブジェクト参照 | Order → Customer | 高 | CustomerId 参照に変更 |
## To-Be ドメインモデル図（改善案）
[Mermaid classDiagram - 改善後]
## リファクタリング優先度
1. **即対応**: [深刻度:高]
2. **次スプリント**: [深刻度:中]
3. **将来的に検討**: [深刻度:低]
「この概念は追跡が必要か（ライフサイクルがあるか）？」
YES → Entity（識別子を持つ）
NO → 「値として等価判定が自然か？」
YES → Value Object（イミュータブルにする）
NO → 再検討（ドメイン知識が足りない可能性）
「このオブジェクト群は、常に一貫した状態でなければならないか？」
YES → 同じAggregate
NO → 別のAggregate（IDで参照する）
「整合性が必要なのはいつか？」
即時（同一トランザクション） → 同じAggregateを検討
最終的整合性でよい → 別Aggregateにして Domain Event で連携
「集約の状態変化を他の集約・コンテキストに伝える必要があるか？」
YES → Domain Event を発行する
「副作用（メール・在庫更新・ログ）を集約から分離したいか？」
YES → Domain Event で疎結合にする
「同じ言葉が異なるチームで異なる意味を持っているか？」
YES → 別の Bounded Context
「このチームの変更が別のチームの変更を強制するか？」
YES → 境界が必要 → Context Map でパターンを選択
God Aggregate: Order が Cart・Payment・Shipping・Inventory をすべて含む 解決: ドメインイベントで集約間連携に分割（Vernon の原則2: 小さな集約）
貧血ドメインモデル: ドメインオブジェクトが getter/setter のみ、ロジックはすべてサービス層 解決: 不変条件の保護・状態遷移をエンティティ自身に移動
DBスキーマ思考のドメインモデル: テーブル設計をそのままクラスにしたモデル 解決: ドメイン概念から設計し、Repository で永続化を分離
Bounded Context 未設定のまま単一モデル: "Product" が在庫・EC・物流で同じクラス 解決: コンテキストごとに独立したモデルを定義
双方向参照の多用: Order ↔ Customer ↔ OrderItem が相互参照 解決: 主たる方向を一方向に固定し、逆方向はクエリで取得
イミュータブルでない Value Object: Money の amount を直接変更している
解決: VO は新しいオブジェクトを返す（money.add(other) → 新しい Money を返す）
集約間で直接オブジェクト参照: order.customer.email のようなアクセス
解決: 別集約への参照は ID のみ（order.customerId）
技術的 ID をドメインイベントに含める: DB のサロゲートキーをそのままイベントに
解決: ドメインの識別子（OrderId 型等）を使う
詳細な設計原則・具体例・Mermaid 記法は上記参照ドキュメントを読み込む。
設計結果は以下の形式でまとめる:
## ユビキタス言語
Step 1〜7 を通じて育てた最終版の語彙表。図内のすべての名称はこの表と一致する。
| 用語 | 定義 | 文脈 | 除外する言い方 |
|------|------|------|--------------|
| 注文 | 顧客が確定した購入申し込み | 販売 | 「受注」は使わない |
| 発注 | 仕入先への購入依頼 | 仕入 | 「注文」と混同しない |
| 在庫引当 | 特定注文のために在庫数を確保する操作 | 在庫 | — |
## Bounded Context
| Context | 責務 |
|---------|------|
| Order Management | 注文の作成から完了まで |
## Context Map
[Mermaid graph で BC 間の関係を表現]
## ドメインモデル図
[Mermaid classDiagram で集約・Entity・VO を表現]
## 設計判断の根拠
- なぜ X を Entity にしたか
- なぜ Y を VO にしたか
- なぜ Z を別集約にしたか
会話中の話題を、最小の視覚表現（擬似コード・呼び出しツリー・コンポーネントツリー・ファイルツリー・Mermaid・diff・HTML）で見せて理解を助けるスキル。「図で説明して」「見せて」「視覚的に説明して」「イメージで教えて」「構造を見せて」「どう変わるのか見せて」「show me」などで発動する。説明が長文になりそうなときに、文章の代わりに図で示す。
agent-flow の orchestrator 向け高精度タスク分解・戦略選択スキル。要求を分析し、7パターン（map-reduce 含む）＋複合パターンから最適な戦略を選定し、実行可能なタスクグラフを生成する。decomposition スキルの分解能力を内包し、agent-flow の `--planner flow-planner` で利用する。
セッションをまたいで知識・決定事項を継続させたいときのスキル。「覚えておいて」でsave、「思い出して」でrecall、「記憶一覧」でlist、「忘れて」でarchive、「共有して」でshare、「整理して」でcleanup、「役立った／間違ってた」でrate、「固定化して」でconsolidate。重要な知見を発見したら自律的にsaveを実行すること。
基于 SOC 职业分类