domain-modeling について
ソフトウェアプロジェクトのドメインモデルを整えるスキルです。用語の明確化や境界ケースの検討を促し、用語集やアーキテクチャ決定をその場で記録するための形式と検証方法も定めます。
主な機能
- 01曖昧または不一致な用語の明確化
- 02シナリオを使ったドメイン関係の検討
- 03確定した用語の用語集への記録
- 04重要なトレードオフのADR化
- 05形式に沿った用語集エントリの検証
活用シーン
- 01プロジェクト内のドメイン用語の統一
- 02ドメイン概念間の境界ケースの検討
- 03合意した定義の随時文書化
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/domain-modelingを入力して読み込まれたか確認します。
詳細
ドメインモデリング
設計を進める中で、プロジェクトのドメインモデルを積極的に構築し、磨き上げてください。これは積極的に取り組む規律です。用語に疑問を投げかけ、エッジケースのシナリオを考案し、用語集や決定事項が固まったその場で書き留めます。語彙を知るために用語集を読むだけでは、このスキルを実践したことにはなりません。それはどのスキルでもできる、たった一行の習慣です。このスキルが対象とするのは、モデルを単に参照するのではなく、変更するときです。
ドメインモデルは次の2か所にあります。
- 用語集 —
docs/glossary/に用語ごとに1つの Markdown ファイルを置き、uvx disambiguateが想定する形式にします（詳細は以下を参照）。ルートにCONTEXT.mdを置いてはいけません。 - 決定事項 —
writing-adrsスキルに従った ADR をdocs/adr/に置きます。
用語集の項目、ADR、ドキュメントは、利用可能であれば writing-prose スキルを使って作成・確認し、markdown として提示してください。正確さと理解しやすさを損なってはいけません。
ファイルは必要になったときだけ作成してください。docs/glossary/ が存在しない場合は、最初の用語が確定した時点で作成します。
セッション中
用語集と照らし合わせて確認する
ユーザーが docs/glossary/ にある既存の用語と矛盾する用語を使った場合は、すぐに指摘してください。「用語集では『cancellation』をXと定義していますが、今おっしゃっているのはYのようです。どちらでしょうか？」
曖昧な表現を明確にする
ユーザーが曖昧な用語や複数の意味を持つ用語を使った場合は、正確で標準的な用語を提案してください。「『account』と言っていますが、Customer と User のどちらを指していますか？この2つは異なる概念です。」
具体的なシナリオについて話し合う
ドメインの関係性について話し合う際は、具体的なシナリオを使って検証してください。エッジケースを探り、概念の境界をユーザーが明確にせざるを得ないようなシナリオを考案します。
コードと相互参照する
ユーザーが何かの仕組みを説明したら、コードと一致しているか確認してください。矛盾があれば指摘します。「コードでは Order 全体をキャンセルしていますが、先ほど一部キャンセルが可能だと言っていました。どちらが正しいでしょうか？」
用語集をその場で更新する
用語が確定したら、その場で用語集ファイルを書きます。後でまとめて処理するのではなく、確定した時点で記録してください。
用語集の項目には、実装の詳細を一切含めてはいけません。用語集は仕様書でも、作業メモでも、実装上の決定事項を保管する場所でもありません。用語集は用語集であり、それ以外のものではありません。
ADR の提案は慎重に行う
writing-adrs スキルで定める3つの条件をすべて満たす場合に限り、ADR の作成を提案してください（覆すのが難しい、背景がなければ意外に感じられる、実際のトレードオフの結果である）。形式、番号付け、保存場所も writing-adrs に従います。
用語集の項目の形式
uvx disambiguate で利用できるよう、docs/glossary/ に用語ごとに1つのファイルを置きます。
- ファイル名はスラッグにする：小文字、数字、単一のハイフンを使います（
order-line.md→ スラッグorder-line）。スラッグは一意でなければなりません。 - 最初の H2 は標準名にする（必須）：
## Order Line。 - 本文は自由形式の Markdown：用語が何であるかを定義する簡潔な文を1〜2文で書きます。用語が何をするかは書きません。同じ概念に複数の呼び方がある場合は、最適なものを選び、他の呼び方を
_Avoid_:の下に列挙します。 - 関連用語を相互参照するには、ベース名を使った標準的な Markdown リンク（
[Customer](customer.md)）または Wiki 形式（[[customer]]）を使います。これらのリンクはdisambiguateがトポロジカル順に表示する依存関係グラフを構成します。別の用語に基づく用語には、その用語へのリンクが必要です。
docs/glossary/invoice.md の例：
## Invoice
A request for payment sent to a [Customer](customer.md) after delivery.
_Avoid_: Bill, payment request
ルール：
- 明確な方針を持つ。 概念ごとに標準用語を1つ定め、競合する呼び方は
_Avoid_の下に記載します。 - このプロジェクトの文脈に固有の用語だけを含める。 プロジェクトで頻繁に使われていても、タイムアウト、エラーの種類、ユーティリティパターンなどの一般的なプログラミング概念は含めません。
- 編集後、
uvx disambiguate --lintで検証します。