domain-modeling

ドメインモデリング

プロジェクトのドメイン概念と、それらを形作る決定を明確にします。これらの意味を定義または改訂するときにこのスキルを使います。既存の用語集を読むだけの場合は、モデリングセッションは必要ありません。

作業モードを選択する

• 議論または編集の提案： 議論、レビュー、読み取り専用の依頼では、定義、決定、提案するドキュメント変更を会話内に留めます。ファイルの作成や編集は行いません。
• ドキュメントの更新： ユーザーがドメインドキュメントの作成または保守を依頼した場合、または記録を含むワークフローを依頼した場合は、その範囲内で確定した用語と、それに関する決定を記録します。すでに与えられている許可に従い、項目ごとに再確認を求める必要はありません。書き込み先が特定のドキュメントに限定されている場合、その他の記録案は会話内に留めます。

このスキルを読み込んだだけでは、ドキュメントへの書き込みは許可されません。依頼によって書き込みの意図が明確になっていない場合は、議論モードを続けます。モデルを記録しても、その実装やコードの名前変更が許可されるわけではありません。

既存のドキュメントを確認する

リポジトリのガイダンスと関連ドキュメントを調べ、現在の用語集、コンテキストマップ、ADR の保存場所、ドキュメント形式を確認します。何かを作成する前に、既存の名前、リンク、コンテキストの所有権、番号付けに従います。用語集や ADR ディレクトリの名前が異なっていても、ドキュメントが存在しないとは限りません。

規約がない場合は、ドメイン用語に CONTEXT.md を、アーキテクチャ上の決定に docs/adr/ を使用します。記録すべき合意済みの内容があり、ドキュメント更新モードの場合にのみ、これらを作成します。既存のコンテキストマップがあれば、ファイル名にかかわらず、それを使ってドメイン固有の記録を探します。ルートに CONTEXT.md があるというだけで、プロジェクト全体にコンテキストが1つしかないと判断しないでください。

セッション中

用語集との照合

意図された意味を用語集と照らし合わせます。矛盾によってドメイン上の区別、動作、所有権、または契約が変わる場合は、確認します。同じ概念を明らかに指している単なる同義語や表現の違いでは、議論を中断する必要はありません。回答では確立済みの用語を使います。

曖昧な表現を明確にする

文脈と利用可能な証拠を使って、多義的な用語を解釈します。意味の異なる複数の解釈が依然として妥当な場合は、その違いを説明し、焦点を絞った質問をします。役立つ場合は標準的な用語を提案しますが、その提案を合意済みの変更として扱ったり、一貫性だけを理由に表現を規制したりしないでください。

具体的なシナリオについて話し合う

具体的なシナリオによって妥当な解釈を区別できる場合や、未解決のドメインルールが明らかになる場合は、それらを使います。現在の決定を変え得るケースに焦点を当て、議論を長引かせるためだけに例外的なケースを作り出さないでください。

コードと照合する

現在の動作を確認できる場合や、重要な違いを明らかにできる場合は、関連するコードを確認します。実装済みの動作と、ユーザーが意図するモデルは区別します。両者が異なる場合は、ユーザーが予定している変更について説明しているのか、古くなったドキュメントを修正しているのか、不整合を解決しているのかを確認します。コードが追いついていないというだけで、明示された決定を再検討しないでください。

確定した意味を記録する

ドキュメント更新モードでは、用語の意味が確定した時点で、既存の用語集に記録します。議論モードでは、合意した定義または提案する文面を回答内に留めます。プロジェクトに確立された形式がない場合にのみ、CONTEXT-FORMAT.md を使います。

用語集の項目は、ドメイン上の意味に焦点を当てます。実装上の決定は定義ではなく、適切なアーキテクチャ記録に記載します。未解決の提案や仮定は、合意済みの内容と区別します。既存ドキュメントの無関係なセクションはそのまま保持し、多目的の CONTEXT.md を用語集専用のファイルに作り変えないでください。

ADR として記録するのは、条件を満たす決定のみです

次の3つすべてに当てはまる決定は、ADR の対象となります。

1. 覆すのが難しい：後で考えを変えるコストが大きい
2. 背景がないと意外に思われる：将来の読者が「なぜこの方法にしたのだろう？」と疑問に思う
3. 実際のトレードオフ、または外部からの制約の結果である：現実的な選択肢が複数あり、具体的な理由からそのうちの1つを選んだ。または、コードからは見えない制約により、明白な選択肢を採用できなかった

いずれか1つでも当てはまらない場合は、ADR を作成したり、提案したりしないでください。ドキュメントの更新がすでに承認されている場合は、条件を満たす確定済みの決定を、改めて承認を求めることなく記録してください。それ以外の場合は、会話の中で記録を提案してください。プロジェクトの ADR 形式に従ってください。規約がない場合は ADR-FORMAT.md を使用してください。条件を満たす決定の例も記載されています。

完了

確定した意味と決定、重要な未解決の質問、更新または提案したドキュメントを要約してください。書き込んだ内容を読み返し、合意した意味を表現し、既存の文脈が保たれていることを確認してください。議論モードで、提案したテキストが保存されたと主張しないでください。