ソフトウェアプロジェクトを開始するときにチームが最初にすべきことは、コンテキストマップを描くことである。これによってコンテキストとその コアドメインが何であり、そしてチームがやり取りする必要があるかもしれない他のコンテキストが何であるかをチームが理解するのに役に立つ。内容を理解支援、があり、他のどのような文脈彼らと対話する必要があるかもしれません。最も重要なことは、ソフトウェア開発に携わるすべての人の間でドメインの共通の理解を得ることである、とコンサルタントかつコーチであるPaul Rayner氏は、Domain-Driven Design, DDDをやっているチームがどんな種類のドキュメントを作るべきか、という質問に対する答えとして、説明している。
氏は目的、何故は我々は文書化するのかを理解することから始めている。それぞれの文書がどのような目的を果たすのか？あなたの読者を考えて、そこに文書を当てはめる。読者は、技術側なのかビジネス側の人間なのか？これは技術向けなのかビジネス向けのドキュメントなのか？氏が書いているように、「あなたの読者を尊重せよ」。
もう一つ重要な質問は、時間についてである。この文書はチームが今開発しているソフトウェアをサポートするつもりなのか将来の開発をサポートする予定なのか？
開発中にチームをサポートするために、Paulが提案するのは、文書化を好きになること（進行中の、遅れのない活動として）で、そうすると一回作って終わりの文書でなく、文書が正しく、信頼のできるものになる可能性が高くなる。
将来の開発に対して、Paulは、知識をコードでは見つけられない、と考えており、テストや特に文書に関連する他の成果物を支持している。この種の知識を文書化しないと、システムが最終的にどうやって動いているのかを本当にわかっている人がいなくなる。知識が失われるのだ。
Paulが見つけたのは、アジャイルチームはしばしばシステムが何をする必要があるのかを記述するのに、もっと詳細な要求仕様よりも軽量なアプローチのほうを好む、ということである。要求仕様にある１つの問題は、不十分なドメインと技術知識によって設計上の決定が余りに早く行われ、設計と実装が乖離することである。氏はMary Poppendieckの言葉を引用している。
余りに頻繁に起きるのは、詳細な要求リストとストーリーのバックログが、素人によって作られた実際にひどいシステム設計なことである。
BDD
Paulは、システムの生きた文書を作成するのにBDD ツールを使うことの大ファンである。彼はツールとしてCucumberが好きである。その理由は、それが技術的な実装からユビキタス言語の分離を促進するからである。
Paul Raynerは、熟練の設計コーチ、リーダーシップのメンターで、 DDD, BDD、リーン/アジャイルプロセスを使って開発している。DDD Exchange 2012で Paulは、Domain Scenarios to Drive Modelling Whirlpoolというプレゼンテーションを行った。