メニュー
DDD の戦術的設計パターンに基づくドメインモデル設計を支援。エンティティ、値オブジェクト、集約、ドメインサービスの設計。「ドメインモデルを設計したい」「DDD で設計したい」「集約を定義したい」「エンティティと値オブジェクトを識別したい」「ユビキタス言語を整理したい」といった場面で発動する。ドメインモデルを先に設計することで、業務ロジックが実装コードに正しく反映される。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Marp Markdown スライドデッキの作成・拡張・再生成を支援。PlantUML 図表、AI 画像バリアント、漫画画像バリアント、PPTX/HTML 出力に対応。`tmp/k2works-wiki/スライド/YYYYMMDD` などの日本語技術スライドフォルダの構築・更新、コードサンプル追加、ビジュアル要約スライド追加、`スライド.images.md` / `スライド.images.ai.md` / `スライド.images.ai.manga.md` の生成、Marp HTML/PPTX デッキの再生成時に使用。
テスト駆動開発から始めるプログラミング入門」の対話式チュートリアル。FizzBuzz を題材に TDD の Red-Green-Refactor サイクルを 14 言語で体験する。「TDD を練習したい」「FizzBuzz で TDD を学びたい」「テスト駆動開発の入門をしたい」「Java で TDD を体験したい」「Python で TDD を始めたい」「プログラミング入門チュートリアルをやりたい」「getting-start-tdd をやりたい」「TDD のハンズオンがしたい」「Red-Green-Refactor を体験したい」といった場面で発動する。TDD チュートリアルやプログラミング入門の要望があれば積極的に使用すること。
ビジネスアーキテクチャ分析を支援。要件定義の前段階として、ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ、組織マップ、情報マップ、ビジネスシナリオを作成。「ビジネスモデルを整理したい」「バリューストリームを描きたい」「ケイパビリティマップを作りたい」「事業構造を分析したい」「ビジネスアーキテクチャを分析したい」「BA 分析をしたい」といった場面で発動する。ビジネスの全体像を理解してからシステム要件に落とし込むことで、本当に必要な機能を見極められる。
企業事例（ケーススタディ）の与件文作成を支援。経営戦略・マーケティング・生産管理・財務会計の 4 パターンから選択し、テンプレートのプレースホルダに対応する質問に回答することで与件文を生成する。「企業事例を作りたい」「ケーススタディを書きたい」「与件文を作成したい」「診断士試験の事例問題を作りたい」「仮想企業の事例を整理したい」といった場面で発動する。事例テンプレートに沿って体系的にヒアリングすることで、論理的整合性のある与件文を効率的に作成できる。
企業事例（与件文）を基に企業戦略・事業戦略・機能戦略の 3 階層を体系的に立案。環境分析（SWOT・VRIO・BMC）から始めて、ドメイン定義・成長戦略・競争戦略・価値連鎖・ケイパビリティマップまで、PlantUML を活用した可視化ドキュメントを作成する。「戦略を立案したい」「企業戦略を作りたい」「事業戦略を策定したい」「SWOT 分析をしたい」「VRIO 分析をしたい」「成長戦略を考えたい」「競争戦略を立てたい」「価値連鎖を分析したい」「ケイパビリティマップを作りたい」「診断士試験の戦略分析をしたい」「企業事例から戦略を導出したい」といった場面で発動する。事例と戦略をセットで扱うことで、経営コンサルティングの提案書や中小企業診断士の答案に相当する体系的な戦略ドキュメントを作成できる。
インセプションデッキの作成を支援。プロジェクトの「なぜ」「何を」「どうやって」を 10 の問いで整理し、チーム全体の認識を揃える。「インセプションデッキを作りたい」「プロジェクトの方向性を整理したい」「10 の問いに答えたい」「チームの認識を揃えたい」「プロジェクトを立ち上げる」といった場面で発動する。プロジェクトの方向性を最初に揃えておくことで、後工程での手戻りを大幅に減らせる。
| 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 を使用してクラス図・オブジェクト図を作成する。図はコードと同様にバージョン管理し、設計の変更を追跡可能にせよ。
コンテキストの戦略的分類には Mermaid.js の Quadrant Chart を使用する。
quadrantChart
title 差別化の度合いと業務ロジックの複雑さによる業務領域の分類
x-axis "低い差別化" --> "高い差別化"
y-axis "低い複雑さ" --> "高い複雑さ"
quadrant-1 "中核"
quadrant-2 "一般"
quadrant-3 "一般または補完"
quadrant-4 "補完"
"Aコンテキスト": [0.75, 0.82]
"Bコンテキスト": [0.82, 0.68]
"Cコンテキスト": [0.62, 0.60]
"Dコンテキスト": [0.28, 0.42]
"Eコンテキスト": [0.65, 0.28]
"Fコンテキスト": [0.30, 0.65]
"Gコンテキスト": [0.18, 0.22]
docs/design/domain-model.md として出力する既存の docs/design/domain-model.md がある場合は、まずその内容を確認する。不足しているドメインオブジェクトや集約境界の見直しが必要な部分のみを修正する。
Example:
ユーザー: 「エンティティは識別した。集約の境界を決めたい」
回答: 既存の domain-model.md のエンティティ一覧を確認し、
トランザクション整合性が必要な範囲を分析して集約境界を定義する。
集約ルートを決定し、不変条件を明記する。
orchestrating-analysis — 分析フェーズ全体のワークフロー案内analyzing-architecture — 前段のアーキテクチャ設計analyzing-data-model — 並行して進めるデータモデル設計analyzing-usecases — 入力となるユースケース・ユーザーストーリー