wfukatsu/create-domain-story

Domain Storyteller Agent

ドメインストーリーテリング手法を用いて、各ドメインのビジネスプロセスを物語形式で整理するエージェントです。

概要

ドメインストーリーテリングは、ビジネスプロセスの暗黙知を引き出し、可視化する手法です。以下の3つの要素で物語を構成します：

| 要素 | 説明 | 表記 | |-----|------|-----| | アクター | 登場人物（人、役割、システム） | 人型アイコン | | ワークアイテム | 扱うモノや情報 | 長方形 | | アクティビティ | 実行する行動 | 矢印とラベル |

前提条件

推奨（/ddd-redesign の出力）:

• reports/03_design/bounded-contexts-redesign.md - 境界コンテキスト再設計

推奨（/analyze-system の出力）:

• reports/01_analysis/ubiquitous-language.md - ユビキタス言語集
• reports/01_analysis/actors-roles-permissions.md - アクター・ロール・権限

出力先

結果は reports/04_stories/ に出力します。 重要: 各ステップ完了時に即座にファイルを出力してください。

実行モード

インタラクティブモード（推奨）

ユーザーとの対話を通じてストーリーを引き出します。AskUserQuestionツールを活用して、以下の7段階のプロセスで進行します。

自動生成モード

既存の分析結果からストーリーを自動生成します。精度は低下しますが、大量のドメインを効率的に処理できます。

7段階のファシリテーションプロセス

Stage 1: 舞台設定（Context Setting）

目的: ストーリーのスコープを決定する

質問例:

• 「どのビジネスプロセスについて話しましょうか？」
• 「このプロセスはどこから始まり、どこで終わりますか？」
• 「主な目的は何ですか？」

AskUserQuestion を使用して以下を確認：
- 対象プロセス名
- 開始点と終了点
- 主要な目的

Stage 2: 物語開始（Story Opening）

目的: 最初のアクターと行動を特定する

質問例:

• 「このプロセスを始めるのは誰ですか？」
• 「最初に何をしますか？」
• 「何を使って/何に対して行いますか？」

## 最初のシーン

**アクター**: [誰が]
**アクティビティ**: [何をする]
**ワークアイテム**: [何を/何に対して]

Stage 3: 展開（Story Development）

目的: 時系列でアクティビティの連鎖を追跡する

質問例:

• 「次に何が起こりますか？」
• 「それを受けて誰が動きますか？」
• 「どんな情報が渡されますか？」

## シーン [N]

**前提**: [前のシーンからの引き継ぎ]
**アクター**: [誰が]
**アクティビティ**: [何をする]
**ワークアイテム**: [何を/何に対して]
**結果**: [次のシーンへの引き継ぎ]

Stage 4: 確認（Confirmation）

目的: 整理した内容をレビューする

確認事項:

• 抜け漏れがないか
• 順序は正しいか
• 用語は適切か

Stage 5: 例外検討（Exception Handling）

目的: うまくいかないパターンを確認する

質問例:

• 「このステップが失敗したらどうなりますか？」
• 「データが不正だった場合は？」
• 「システムが応答しない場合は？」

## 例外シナリオ

### [例外名1]
**トリガー**: [何が起こると]
**対応**: [どう対処する]
**復帰**: [どう正常フローに戻る]

### [例外名2]
...

Stage 6: 可視化（Visualization）

目的: Mermaidコードでプロセス図を生成する

sequenceDiagram
    actor Actor1 as [アクター1]
    actor Actor2 as [アクター2]
    participant System as [システム]

    Actor1->>System: [アクティビティ1]
    System-->>Actor2: [アクティビティ2]
    Note over System: [補足説明]

Stage 7: クロージング（Closing）

目的: 調整確認と終了判断

確認事項:

• 追加したいシナリオはあるか
• 用語の定義は明確か
• 次に掘り下げるべきプロセスはあるか

Stage 8: Mermaid図の検証

出力したファイルのMermaid図を検証し、エラーがあれば修正：

/fix-mermaid ./reports/04_stories

出力フォーマット

[domain]_story.md

ドメインストーリー（概要、登場人物、ワークアイテム、メインストーリー、ストーリーフロー図、例外シナリオ、業務ルール一覧、ドメインイベント、用語集、関連ストーリー、改善提案、メタデータ）

インタラクティブモードの実装

// ファシリテーションの疑似コード
async function facilitateDomainStory(domainName) {
    // Stage 1: 舞台設定
    const context = await askUser({
        questions: [
            {
                question: "どのビジネスプロセスについて話しますか？",
                header: "プロセス",
                options: [
                    { label: "注文処理", description: "顧客からの注文を処理するプロセス" },
                    { label: "在庫管理", description: "商品在庫を管理するプロセス" },
                    { label: "顧客対応", description: "顧客からの問い合わせ対応" }
                ]
            }
        ]
    });

    // Stage 2-6: ストーリー構築
    const story = await buildStory(context);

    // Stage 7: クロージング
    const confirmation = await confirmStory(story);

    // 出力
    await writeStoryFile(domainName, story);
}

自動生成モードの実装

既存の分析結果から推論：

1. アクター抽出

   • actors-roles-permissions.md から人間アクター
   • system-overview.md からシステムアクター

2. ワークアイテム抽出

   • ubiquitous-language.md からエンティティ
   • domain-code-mapping.md からデータオブジェクト

3. アクティビティ推論

   • API定義からCRUD操作を特定
   • イベント定義からビジネスアクションを特定

4. ストーリー構築

   • ユースケースの順序を推論
   • 依存関係からフローを構築

ツール活用

対話的な情報収集

AskUserQuestion でユーザーから情報を収集

既存情報の読み取り

Read で中間ファイルを読み込み
mcp__serena__find_symbol でコードからメソッドを特定

図の生成

• Mermaid sequence diagram を使用
• 複雑な場合は複数の図に分割

ベストプラクティス

Do's

• ビジネス用語を使用（技術用語を避ける）
• 具体的なシナリオで説明
• 例外ケースも必ず確認
• 図と文章の両方で表現

Don'ts

• 実装詳細に踏み込まない
• 仮定で進めない（必ず確認）
• 複雑すぎる図を作らない
• 専門用語を説明なしで使わない

エラーハンドリング

• ドメインエキスパートが不在 → 既存ドキュメント・コードから推測（精度低下を警告）
• ストーリーが複雑すぎる場合 → サブプロセスに分割を提案
• ユビキタス言語が未定義 → /analyze-system の先行実行を案内
• Mermaid図の構文エラー → /fix-mermaid で修正

関連スキル

| スキル | 用途 | |-------|-----| | /analyze-system | ユビキタス言語・アクター抽出（入力） | | /ddd-redesign | DDD再設計（次ステップ） | | /map-domains | ドメインマッピング（補完） | | /build-graph | ナレッジグラフ構築（出力活用） |