ddd-requirements-modeling
要件文を受け取ったら、頭の中では次の順で考え、出力は「全体像」「詳細（仮）」「決めてもらうこと」の順で書く。読む人はまず図で全体を掴みたいので、詳細を先に出さない。
方針: 大抵の業務アプリに DDD は要らない。業務領域ごとに、基本の技術構成で素直に作るところから始め、要件に上げる理由があるときだけ次の段階に上げる。DDD の形に揃えること自体を目的にしない。
DDD、テスト駆動開発、クリーンアーキテクチャなどの技法も同じで、技法が解決する問題が要件文にあるときだけ持ち込む。相応しくない状況に当たる業務領域には持ち込まない。判断表は references/technique-fit.md。
| 段階 | 作り方 | 使う部品 |
|---|
| レベル1 | 基本の技術構成で素直に作る。MVC か、外部とのやりとりがあればポートとアダプター | 主体の型と、主体を受け取って確認・加工する関数 |
| レベル2 | レベル1に、厳選したデザインパターンを当てて疎結合にする | 逆引き表の 11 パターンから最大 3 件 |
| レベル3 | 複雑さが最初から見えている部分にだけ、DDD の部品を持ち込む | 集約、エンティティ、値オブジェクト、リポジトリ、ユースケース。必要ならイベント履歴式、CQRS、サーガ |
主体は、業務の中心となるデータを指す。ベルトコンベアで流れてきて、確認や加工を受けて完成品になる物にあたる。レベル3では主体を集約として扱う。
基本の技術構成は Next.js（App Router）、Prisma、SQLite、Tailwind CSS 4 以上で、その時点の最新安定版を使う。Next.js の外に出す理由があるときだけ、TypeScript の Hono か Python の FastAPI で別サーバーを立てる。
トランザクションスクリプトは使わない。Server Actions や Route Handler の 1 つの関数に、入力確認・計算・保存・通知を上から並べて書かない。主体を受け取って確認・加工する関数を業務領域ごとのモジュールに置き、Controller には呼ぶ順番だけを残す。
考える順番:
- 要件を 1 文で言い切る
- 業務領域を分け、中核・一般・補完に分類する
- 業務領域ごとに作り方の段階を判定する。既定はレベル1
- 同じ言葉を拾い、意味が 2 つある言葉に印を付ける
- 主体と守る決まりを決める。レベル3の業務領域だけ、区切られた文脈と集約に切り、つながり方を決める
- 構成（MVC、ポートとアダプター、ドメインモデルなど）と、別サーバーの要否を決める
- レベル2以上の業務領域だけ、デザインパターンを選ぶ（
references/gof-patterns.md の逆引き表にある 11 パターンからだけ）
- 決めてもらう質問を絞る。答えが出るまで要件が不明瞭な業務領域は、テストから先に書くかを決める
判断基準はこのファイルと references/ の手引きにまとめてある。該当するステップの前に必要な手引きを読み、要件のどの条件に基づく判断かを説明する。
| ステップ | 読む参照ファイル |
|---|
| 2、4 | references/ddd-strategic.md（業務領域の分類、同じ言葉） |
| 3、6 | references/ddd-heuristics.md（作り方の判定、各段階の構成、別サーバーを立てる判断） |
| 5 | references/ddd-tactical.md（主体と決まりの見つけ方、テーブルの当たり。レベル3では集約の境界ルールと部品の役割）。レベル3で文脈を切るときは references/ddd-strategic.md の区切られた文脈と連係方法 |
| 7 | references/gof-patterns.md（techscore を根拠に 23 から 11 に絞った逆引き表、Facade の判断基準、表に入れない 12 の書き方、選び分け。絞った根拠は references/gof-review-2026.md） |
| 2、3、6、8 | references/technique-fit.md（技法の向き不向き。各ステップで技法を持ち込むかを決める共通の関門。中核の見極めは 2、集約などの部品は 3、クリーンアーキテクチャは 6、テスト駆動開発は 8） |
| 全体の流れ | references/ddd-heuristics.md（必要な動作の整理、設計結果の確認） |
出力の形（ここが一番大事）
文書は assets/output-template.md の見出し構成をそのまま使う。3 層になっている。段階によって書く節が変わる。
| 層 | 中身 | 目安 |
|---|
| 1. 全体像 | 主体のつながりの図、中核とそれ以外の表、作り方の判定表、必要な機能の表 | 画面 1 枚に収まる量。図 1 つと表 3 つ |
| 2. 詳細（仮） | 同じ言葉、必要な動作の表、主体と守る決まり、テーブルの当たり。レベル3があれば文脈のつながり方、レベル2以上があればデザインパターン | 動作の表以外は各表 10 行以内。1 主体 1 行 |
| 3. 決めてもらうこと | 答えで図や表が変わる質問だけ | 最大 8 個 |
全体で 150 行以内を目安にする。レベル1だけの文書はもっと短くてよい。長くなるときは詳細を削り、全体像は削らない。
全体像の図
Mermaid の flowchart TB で描く。レベル1・2の業務領域は業務領域を subgraph にし、その中に主体だけを箱で置く。レベル3の業務領域は区切られた文脈を subgraph にし、その中に集約のルートだけを置く。値オブジェクトやエンティティの中身は図に入れない。既存システムや外部サービスは別の subgraph にまとめる。矢印は 2 種類だけ使う。どちらも上流から下流へ、つまり材料が流れる向きに引く。実線は「材料として渡す（下流が上流を ID で参照する）」、点線は「〜されたら知らせる（業務イベント）」。ID 参照の向き（下流から上流）に矢印を引かない。読む人は図を工程の流れとして見るので、参照の向きで引くと逆に見える。上流の箱を上に、下流の箱を下に置く。レベル3の文脈をまたぐ矢印には連係パターン名を書く。物理配置図やテーブル関連図にはしない。
図を書いたら、矢印を上から順に読んで「工程の流れ」として読めるかを確かめる。矢印のラベルに「ID で参照」と書きたくなったら向きが逆の印なので、上流の箱を始点にして「何を渡すか」をラベルにする。ID 参照の向きは「主体と守る決まり」の表の「他の主体への参照（ID）」列で示す。
図の下に 2〜3 行で読み方を書く。どこが中心で、何が起きると何に伝わるか。ここで「主体」という言葉を初出として説明する。レベル3の業務領域があるときは、「区切られた文脈（Bounded Context）」「集約（Aggregate）」もここで初出として出し、以降もこの呼び方を使う。レベル3が無い文書には、区切られた文脈・集約という語を出さない。
中核とそれ以外の表
業務領域ごとに 1 行。種類と一言の理由と方針（自前で作り込む・既製品・素直に作る・後回し）だけ。判断するのは「競合との差になるか」「既製品で済むか」「無いと困るが差にはならないか」。要件文に競合や差別化の記述が無いときは種類に「（仮）」を付ける。
作り方の判定表
このスキルの判断の中心。業務領域ごとに 1 行。列は「レベル2の兆候」「レベル3の兆候」「段階」「構成」。判定の流れと兆候の一覧は references/ddd-heuristics.md の「作り方の判定」。
- 兆候の列には、根拠になる要件文の言い回しを「」で引く。兆候が無ければ「なし」と書く
- 段階を上げた行は、兆候の列だけで上げた理由が分かるようにする
- 構成の列は、MVC、ポートとアダプター、ドメインモデル＋ポートとアダプター、イベント履歴式ドメインモデル＋CQRS のどれか。サーガや送信箱が要るならこの列に一言添える
- 構成の列でポートとアダプターを選ぶかは、
references/technique-fit.md のクリーンアーキテクチャの行で判断する。業務の関数が DB や外部の形に依存して壊れる兆候が無ければ MVC のままにする
- 表の下に、技術構成を 1 行、別サーバーの要否を 1 行、テストから先に書く業務領域を 1 行で書く。別サーバーは
references/ddd-heuristics.md の「別サーバーを立てる判断」の条件に当たるときだけ立てる。当たらなければ「なし」。テストから先に書く業務領域は、references/technique-fit.md のテスト駆動開発の行に当たる業務領域だけを、関係する質問の番号と一緒に書く。当たらなければ「なし」
- 中核とそれ以外の表と食い違うとき（中核なのにレベル1、補完なのにレベル3）は、確定させず質問に回す。どちらとも取れる業務領域は「（仮）」を付け、どの答えなら段階が変わるかを質問にする
必要な機能の表
「ログイン機能」「決済機能」「通知機能」「帳票出力」のような粒度で並べる。要件文の「欲しい機能」をそのまま写すのではなく、業務領域の分類を踏まえて「作る／既製品／後回し」を付ける。一般的な業務領域に当たる機能は既製品を第一候補にする。
詳細（仮）の書き方
- 同じ言葉: 意味が 2 つある言葉を先に表にする。レベル3では、これが文脈を分けた根拠になる。主な用語は 10 個以内。要件文に出てくる全部の名詞を並べない
- 必要な動作の表: 登場人物、外部システム、コマンド、業務イベント、ポリシーを 1 つの表に並べる。
references/ddd-heuristics.md の「必要な動作の整理」に従う。この表は全体像の図の裏付けなので、行数の上限は設けない。ただし 1 行は短く、「何が変わるか」は 1 文
- 文脈のつながり方: レベル3の業務領域があり、他の文脈や外部とつながるときだけ書く。1 組 1 行。連係パターンは
references/ddd-strategic.md の呼び方で書き、初出時に原語を添える
- 主体と守る決まり: 1 主体 1 行。中に持つもの、守る決まり、起こす出来事、他の主体への ID 参照。守る決まりには「DB の一意制約」「入力確認」のように守る場所を短く添えてよい。レベル3では主体を集約として書き、
references/ddd-tactical.md の「集約の境界ルール」を当てる。出力には結果だけを書く
- 構成要素の粒度: レベル1・2では部品に分けない。主体の名前と中に持つものを書くだけにする。レベル3でも、書くのは集約と業務イベントまでを基本にする。値オブジェクト、エンティティ、業務サービス、リポジトリ、ユースケースは次の 2 つがそろったときだけ書く。1 つ目は、その部分の要件が明確に固まっていること。2 つ目は、他のオブジェクトとの連係を考えても、未決の点や質問が残らないこと。どちらか欠けるなら集約の行の「中に持つもの」に名前を書くだけで止める。理由は、要件が動く段階で細かい部品に分けると、要件が変わるたびに部品の切り直しになるから
- 値オブジェクトの採用: レベル3でだけ検討する。要件が固まったこと自体は採用理由にならない。普通の型・構造体と関数で必要な決まりを簡単に守れるなら、その形でよい。値の検証・計算・比較の決まりをひとまとまりにする具体的な利点を、要件に基づいて説明できるときに採用を検討する。採用する場合も専用クラスを必須にしない
- テーブルの当たり: 主体 1 つにつき 1〜2 テーブル。Prisma のモデルになる想定で、主キーと最低限の列と「最低限考慮すること」だけ書く。一意制約、履歴を残すか、削除は論理か、他システムの ID を持つか、時刻の扱い、のうち当てはまるものを書く。列の型や桁は決めない。まだ仮の段階なので詰めない。受付番号や伝票番号のような連番は、アプリ側で「今の最大値 +1」を計算する設計にしない。DB の自動採番か Prisma の採番機能に任せる。理由は、2人が同時に登録すると同じ番号が2つできるから
- 業務上の数値の置き場所: 割引額、料率、上限、締め時刻のような業務上の数値は、計算する関数の中に直書きしない。既定は定数ファイルか JSON のような設定ファイルに、名前を付けてまとめて置く。コードは計算の形だけを持つ。DB の設定テーブルに置くのは、指示されたときだけ。その場合は適用開始日と終了日を持たせ、テーブルの当たりに 1 行足す。設計書には「設定ファイルに置く」と 1 行書き、DB に入れるかどうかは決めてもらうことに回してよい。根拠と判断表は
references/business-values-placement.md
- デザインパターン: レベル2以上の業務領域だけに当てる。レベル1だけの文書では、この節は「レベル1のため該当なし」と 1 行で書く。最大 3 件。逆引き表の 11 パターンからだけ選ぶ。表に無い 12 が当たりそうなら、パターン名を出さず「関数を渡す」「モジュールにまとめる」のように書き方を 1 行で書く。「関数を渡す」と書くときは
references/gof-patterns.md の「関数で差し替えるときの書き方」に従い、名前付き関数と switch か対応表を指定する。Facade は判断基準（外部が 2 つ以上、順番がある、利用者が複数、のうち 2 つ）を満たすときだけ。根拠は techscore だけ。出典は URL 全文を書く。「techscore/State」のような略記にしない。保存や連係の仕組みである「ポートとアダプター」「送信箱」「サーガ」はデザインパターンの表に入れない。判定表の構成の列に書く
決めてもらうことの書き方
仮置きした判断のうち、答えで図や表が変わるものだけを質問にする。最大 8 個。順番は影響が大きい順。段階の判定が変わる質問を優先する。各質問に「分かると何が確定するか」を添える。列の型や画面の細部のような、仮の段階で決めなくてよいことは聞かない。
用語の統一
出力では次の呼び方に統一し、初出時に原語と日常語の説明を添える。
| 原語 | このスキルでの呼び方 | 別の呼び方 |
|---|
| domain | 事業活動 | ドメイン |
| subdomain | 業務領域 | サブドメイン |
| domain logic | 業務ロジック | ドメインロジック |
| domain event | 業務イベント | ドメインイベント |
| Ubiquitous Language | 同じ言葉 | ユビキタス言語 |
| Bounded Context | 区切られた文脈 | 境界づけられたコンテキスト |
| Context Map | 文脈の地図 | コンテキストマップ |
| Shared Kernel | モデルの共有 | 共有カーネル |
| Anticorruption Layer | モデル変換装置 | 腐敗防止層 |
| Separate Way | 互いに独立 | 別々の道 |
| aggregate | 集約 | 集約 |
| aggregate root | 集約のルート | 集約ルート |
| value object | 値オブジェクト | 値オブジェクト |
| entity | エンティティ | エンティティ |
| domain service | 業務サービス | ドメインサービス |
| use case | ユースケース | アプリケーションサービス |
| ports and adapters | ポートとアダプター | ヘキサゴナルアーキテクチャ |
| application architecture | 技術方式 | アーキテクチャ |
| Test-Driven Development | テスト駆動開発 | TDD |
| Clean Architecture | クリーンアーキテクチャ | クリーンアーキテクチャ |
考えるときの要点
参照ファイルを読んだ上で、特に次を守る。
- 段階は、上げる理由を要件文から引けるときだけ上げる。「金額がある」「監査という言葉がある」「中核だから」「項目が多い」「将来複雑になるかも」だけでは上げない
- レベル2の兆候が無くても、レベル3の兆候は必ず確かめる
- 同じ言葉が 2 つの意味を持つ箇所が、文脈を分ける第一の根拠になる。要件文に「担当者によって扱いが違う」「〜の意味が人によって違う」とあれば、それが印。ただし文脈として切るのはレベル3の業務領域だけ
- 区切られた文脈は広い範囲から始める。分けた理由が「同じ言葉の意味が違う」か「別チーム・別システムが持つ」でないなら、1 つにまとめておく
- 主体や集約は「同時に守らなければならない決まり」を守る最小の範囲。「一緒に表示するから」「一緒に保存すると楽だから」は広げる理由にならない。他の主体は ID で参照する
- 守る決まりの範囲が時間とともに増え続ける（ある物件の予約が永久に溜まる など）なら、期間で区切る案を出す
- デザインパターンは「要件文のこの言い回しが逆引き表のこの行に当たるから」と引く。「こういう仕組みが要りそうだから」では当てない
- 技法は「解決したい問題」を要件文から引けて、「相応しくない状況」に当たらないときだけ持ち込む。要件が固まった業務領域にテスト駆動開発を、依存先が DB だけの業務領域にクリーンアーキテクチャを当てない
書き方
- 冒頭の 1 文で結論を言い切る。枕詞は付けない
- 専門用語は初出時に原語を添え、意味を日常語で説明する
- 1 文 1 情報。ダッシュ（—）で補足をつながない。括弧を文中に差し込まない
- コードは出さない
やってはいけないこと
- 要件文に無い機能を足して設計しない。足したくなったら質問にする
- 「たぶんこうだろう」で段階、主体、文脈、集約を確定しない。仮置きには「（仮）」を付ける
- 全部をレベル3にしない。アプリ全体を 1 つの段階にそろえない
- トランザクションスクリプトで書かない。Server Actions や Route Handler に入力確認・計算・保存・通知を全部並べない
- レベル1・2の業務領域に、エンティティ、値オブジェクト、リポジトリ、ユースケース、区切られた文脈を持ち込まない
- 要件に理由が無いのに別サーバーを立てない。レベル3になったことだけでは立てない
- SQL を直接書く設計にしない。Prisma を通す
- 連番をアプリ側で +1 して作らない。DB か Prisma の採番に任せる
- デザインパターンを要件と無関係に選ばない。各パターンの出典は techscore とする
- 逆引き表に無い 12 パターン（Singleton、Strategy、Visitor など）をパターン名で提案しない。言語機能や素朴な書き方で済むと書く
- 主体や集約を大きくしない
- 要件が固まっていない部分を、値オブジェクト、エンティティ、業務サービス、リポジトリ、ユースケースに分解しない。集約と業務イベントで止める
- 詳細を先に書かない。全体像の図と表が先
- 全体像の図の矢印を ID 参照の向き（下流から上流）に引かない。矢印は材料が流れる向き（上流から下流）だけ
- 用語集に要件文の名詞を全部並べない。動作の表と用語集で同じことを二重に書かない
- テーブルの列の型や桁、画面の細部を決めない
- 業務上の数値（割引額、料率、締め時刻など）を計算する関数の中に直書きしない。定数ファイルか設定ファイルに名前を付けて置く。DB に入れるのは指示されたときだけ
- 質問を 8 個より増やさない。仮の段階で決めなくてよいことは聞かない