菜单
DDD の戦術的設計パターンに基づくドメインモデル設計を支援。エンティティ、値オブジェクト、集約、ドメインサービスの設計。「ドメインモデルを設計したい」「DDD で設計したい」「集約を定義したい」「エンティティと値オブジェクトを識別したい」「ユビキタス言語を整理したい」といった場面で発動する。ドメインモデルを先に設計することで、業務ロジックが実装コードに正しく反映される。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
開発フェーズ全体の TDD ワークフローをオーケストレーション。バックエンド・フロントエンドの開発順序と TDD サイクルの実践方法を案内し、Codex 分業体制もサポートする。「開発を始めたい」「TDD の進め方を知りたい」「Codex と分業で開発したい」「開発フェーズの全体像を把握したい」といった場面で発動する。開発フローを標準化することで、品質のブレを防ぎチーム全体の生産性を底上げする。
ビジネスアーキテクチャ分析を支援。要件定義の前段階として、ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ、組織マップ、情報マップ、ビジネスシナリオを作成。「ビジネスモデルを整理したい」「バリューストリームを描きたい」「ケイパビリティマップを作りたい」「事業構造を分析したい」といった場面で発動する。ビジネスの全体像を理解してからシステム要件に落とし込むことで、本当に必要な機能を見極められる。
インセプションデッキの作成を支援。プロジェクトの「なぜ」「何を」「どうやって」を 10 の問いで整理し、チーム全体の認識を揃える。「インセプションデッキを作りたい」「プロジェクトの方向性を整理したい」「10 の問いに答えたい」「チームの認識を揃えたい」「プロジェクトを立ち上げる」といった場面で発動する。プロジェクトの方向性を最初に揃えておくことで、後工程での手戻りを大幅に減らせる。
RDRA 2.0 に基づく体系的な要件定義を支援。システム価値→外部環境→境界→内部構造の 4 層で要件を整理。「要件定義を始めたい」「システムの要求を整理したい」「RDRA で分析したい」「業務フローを整理したい」「システムコンテキストを作りたい」といった場面で発動する。要件を体系的に整理することで、開発フェーズでの「何を作ればいいかわからない」問題を防ぐ。
インセプションデッキの Markdown から PowerPoint スライド（.pptx）を自動生成。pptxgenjs を使用し、テンプレート準拠の 12 枚構成プレゼンテーションを出力する。「スライドを生成したい」「インセプションデッキの pptx を作りたい」「プレゼン資料を出力したい」「スライドを更新したい」といった場面で発動する。Markdown から自動生成することで、内容更新のたびに手動でスライドを作り直す手間を排除する。
設計ドキュメントの一覧表示、進捗確認、内容参照、インデックス更新、Markdown Lint を実行。ドキュメント管理や整備時に使用。
| name | analyzing-domain-model |
| description | DDD の戦術的設計パターンに基づくドメインモデル設計を支援。エンティティ、値オブジェクト、集約、ドメインサービスの設計。「ドメインモデルを設計したい」「DDD で設計したい」「集約を定義したい」「エンティティと値オブジェクトを識別したい」「ユビキタス言語を整理したい」といった場面で発動する。ドメインモデルを先に設計することで、業務ロジックが実装コードに正しく反映される。 |
DDD（ドメイン駆動設計）の戦術的設計パターンに基づき、エンティティ・値オブジェクト・集約・ドメインサービスを設計する。
ドメインモデルの価値は、業務の専門家と開発者が同じ言葉（ユビキタス言語）で会話できるようになること。モデルとコードが一致することで、「仕様と実装の乖離」という根本的な問題を解消する。
| 種類 | パス | 備考 |
|---|---|---|
| ガイド | @docs/reference/ドメインモデル設計ガイド.md | ドメインモデル設計の進め方詳細 |
| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
| 成果物 | docs/design/domain-model.md | ドメインモデル設計 |
ライフサイクルを持ち、識別子で区別されるドメインオブジェクトを識別する。「同じ属性値でも別のものとして扱う必要がある」ものがエンティティ。
不変で識別子を持たないドメインオブジェクトを識別する。「属性値が同じなら同じもの」として扱えるものが値オブジェクト。プリミティブ型の代わりに値オブジェクトを使うことで、バリデーションとドメイン知識をカプセル化する。
トランザクション整合性の境界を定義する。集約が大きすぎると競合が発生し、小さすぎると整合性が保てない。適切な境界の見極めが最も重要。
エンティティにも値オブジェクトにも属さないビジネスロジックを識別する。ドメインサービスは動詞で命名し、ステートレスに保て。
PlantUML を使用してクラス図・オブジェクト図を作成する。図はコードと同様にバージョン管理し、設計の変更を追跡可能にせよ。
docs/design/domain-model.md として出力する既存の docs/design/domain-model.md がある場合は、まずその内容を確認する。不足しているドメインオブジェクトや集約境界の見直しが必要な部分のみを修正する。
Example:
ユーザー: 「エンティティは識別した。集約の境界を決めたい」
回答: 既存の domain-model.md のエンティティ一覧を確認し、
トランザクション整合性が必要な範囲を分析して集約境界を定義する。
集約ルートを決定し、不変条件を明記する。
orchestrating-analysis — 分析フェーズ全体のワークフロー案内analyzing-architecture — 前段のアーキテクチャ設計analyzing-data-model — 並行して進めるデータモデル設計analyzing-usecases — 入力となるユースケース・ユーザーストーリー