BDD についての私の理解では、ユーザー ストーリーでシステムを記述し、開発者がそれらのユーザー ストーリーを取得して、すべての「スプリント」(ソフトウェア開発の期間) で実際のビジネス価値を追加することを意図してアプリケーションに変換します。その結果 (私が知る限り) 、ドメイン モデルは開発プロセス全体のユーザー ストーリーから生まれます。つまり、最初の「スプリント」の後では、ドメイン モデルの多くは設計されていません。
DDD についての私の理解では、ソフトウェア開発は進化しているにもかかわらず、完全なドメイン モデルを参照して継続されます。DDD では、モデルは変更されることが予想されますが、それでも常に「完全」です。
これは、2 つのアプローチの根本的な違いのようです。人々はこれをどのように処理してきましたか？
うまく行われたBDDは、「完全な」モデルを生成しません。BDDを思いついたDanNorthが、自分のブログを「不確実性を受け入れる」と呼んでいるのには理由があります。
最近では、分析できる3種類のこと、つまり、既知、既知、および未知のことを考えると便利だと思います。
既知のものは単純です-たとえば、ログインします。それはよく理解されています。シナリオについて話す必要はありません。
知っていることは通常、ドメイン、または以前に行われたことと関連しています。これは、BDDを実行するのに最適な場所です。これは、ドメインモデルを含む知識をビジネスから開発者に転送するのに役立つためです。シナリオを通して話すことは、物語をよりよく理解するための素晴らしい方法です。また、見逃したシナリオを見つけるのにも役立ちます。「Given」を「Given、When、Then」に入れるのを手伝ったアナリストのChris Mattsは、これを「モデルを壊す」と呼んでいます。彼は実際に、彼のモデルでカバーされていないシナリオを思い付くことができる人に賞品を提供しました。彼はシナリオを使用して定義し、改良します。
知らないものもあります。これは、私たちが何か新しいことに取り組んでいるとき、またはこれまでに行ったことのないこと、または誰も専門知識を持っていない何かに取り組んでいるときに発生します。あなたがこの場所にいるかどうかは、ビジネスマンが思いもよらなかったシナリオを思いついたときに驚きに反応し始めるのでわかります。BDDは、これらの場所を見つけるための非常に優れた方法ですが、この時点で、シナリオを特定するのをやめ、代わりに何かを試してフィードバックを得ることができます。ドメインモデル、ユーザーストーリー、およびシナリオはすべて徐々に出現します（Cynefinモデルの複雑なドメインを参照してください）。
多くのチームがこの不確実性を明らかに排除する方法としてBDDを使用していることを私は知っています。あなたはそれを排除することはできません。後で、配信からのフィードバックが戻ってきてあなたを噛むまで、それを隠すことができます。
DDDに関しては、BDDを使用して行う場合、作業中のシナリオに関連するドメインモデルの部分に焦点を当てる傾向がありますが、全体としてより大きなドメインモデルのアイデアがあるかもしれません。機能インジェクションをBDDと一緒に使用している場合は、システムのほとんどの機能、特に新しい機能についてすでに説明しているので、ドメイン内にどのようなものがあるかがわかります。進化と他のすべてのルールは引き続き適用されます。BDDとDDDは、ドメイン言語を引き出すのに役立つシナリオに関する会話とともに、非常にうまく連携します。それらは根本的に違いはありませんが、完全にサポート的で互換性があります。
ダン・ノースと私自身がこのトピックについて話しているビデオを特集した、この同様の質問に対する私が与えた回答も読んでください。
ユーザー ストーリー、DDD、および BDD は相互に非常に依存しているため、含めます。ここでリンクを要約しようとしました：http://christophelecoent.wordpress.com/2013/06/17/how-to-link-user-stories-ddd-and-bdd/
この図が、これらの「概念」間のリンクを説明するのに十分なほどシンプルで豊富であることを願っています