domain-modeling

ドメインモデリング

ビルドの失敗の多くは、言葉のすれ違いから始まります。エージェントがプロジェクトに投入され、専門用語を推測するしかない状態に置かれるため、ドメインで一つの言葉が使われる場面で、エージェントは二十もの言葉を使ってしまいます。共通言語がこのすれ違いを埋めます。コード、会話、モデルがすべて同じ語彙を使えば、名前に一貫性が生まれ、ナビゲーションのコストが下がります。また、モデルは推論に使う言語がより明確になるため、推論に費やすトークンも少なくなります。

方法

1. 用語を拾い出します。 リクエスト、コードベース、ユーザー自身の言葉から、ドメインの意味を担う名詞と動詞、つまり初心者なら質問せずにはいられない概念を列挙します。自分が好む類義語より、ユーザーが使った言葉を優先します。
2. それぞれを定義します。 辞書の定義ではなく、プロジェクト独自の言葉で一行の定義を書きます。二つの用語が曖昧に重なっている場合は、違いを明確にするか、一つにまとめます。ここでの曖昧さは、コード内の名前の不統一につながります。
3. 境界を描きます。 システムの異なる部分で同じ言葉が別の意味を持つなら、そこが境界です。各コンテキストに名前を付け、どの用語が属するかを記します。二つの意味を持つ用語は、二つの用語です。
4. 重要な判断を記録します。 モデリング上の選択について意見が分かれた場合や、後で疑問が呈されそうな場合は、コンテキスト、選択、退けた代替案、その理由を簡潔な判断記録にまとめます。

成果物

• CONTEXT.md - 共通言語の用語集です。一行につき一つの用語を記載します。 term - このプロジェクトでの意味。複数の境界づけられたコンテキストがある場合は、コンテキストごとにまとめます。今後のすべてのセッションでこのファイルを参照してください。再実行時には新しい用語を追加し、定義が変わったものを更新します。ファイル全体を書き直してはいけません。
• 境界づけられたコンテキストの概略 - 各コンテキストと、そこに属する用語をまとめます。十五秒で読める長さにしてください。
• docs/decisions/NNNN-slug.mdの判断記録 - 議論のあったモデリング上の判断のみを記録します。まずディレクトリを確認し、既存の記録のうち最も大きい番号から採番して、記録が重複しないようにします。明白な判断は省略します。

注意事項

• 用語集は人間だけでなくモデルのためのものでもあります。壁に飾るのではなく、読み込ませることを前提に記述してください。
• プロジェクトで使われていない用語を作り出さないでください。ドメインをそのまま反映し、名前を変えないでください。
• 小さく保ち、最新の状態を維持してください。すべてを列挙して何も更新しない用語集は、用語集がないよりも悪いものです。使われなくなった用語は削除してください。

適用する場面

新しい領域で作業する際は、plan-interrogateの前に実行してください。または、固定できない用語に遭遇したときにplan-interrogateからここに戻るようにします。ここで作成するCONTEXT.mdは、plan-interrogateが出力するものと同じファイルです。一つの共通言語の成果物に、二つの導入経路があります。