我对BDD的理解是，在用户故事中描述系统，然后开发人员将这些用户故事转化为应用程序，目的是在每个"sprint"（软件开发时期）中增加真正的业务价值。结果（据我所知）是域模型在整个开发过程中都是从用户故事中产生的。也就是说，在第一次"sprint"之后，大部分领域模型将不会被设计出来。
我对DDD的理解是，软件开发继续参考全领域模型，尽管这是一个不断发展的模型。在DDD中，模型预计会发生变化，但它始终是"完整的"。
这似乎是两种方法之间的根本区别。人们是如何处理的？
BDD做得好，不会产生"完整"的模型。提出BDD的人Dan North称他的博客为"拥抱不确定性"是有原因的。
如今，我发现思考三种我们可以分析的东西很有用：已知的、可知的和未知的。
已知的东西很简单，例如登录。这是众所周知的。我们不需要讨论这些场景。
已知的东西通常与领域有关，或者与以前做过的事情有关。这是一个进行BDD的好地方，因为它有助于将知识（包括领域模型）从业务转移到开发人员。通过情景对话是更好地理解故事的好方法。它还可以帮助我们找到我们错过的场景。Chris Matts是帮助将"Given"放在"Given，When，Then"中的分析师，他称这是"打破模型"。事实上，他为任何能够提出模型中没有涵盖的场景的人提供了奖品，他使用场景来定义和完善模型。
还有一些不可知的东西。每当我们在做一些新的事情，或者我们以前从未做过的事情，或没有人有专业知识的事情时，就会发生这种情况。你可以判断自己是否在这个地方，因为当你想出他们没有想到的场景时，商界人士会开始惊讶地做出反应。BDD是找到这些地方的一个非常好的方法，但在这一点上，你可能不想再试图确定场景，而是尝试一些东西并获得反馈。您的域模型、用户故事和场景都将逐渐出现（请参阅Cynefin模型中的复杂域）。
我知道很多团队使用BDD来消除这种不确定性。你无法消除它。你只能把它隐藏起来，直到稍后，当交付的反馈回来咬你的时候。
关于DDD，当我们使用BDD时，我们倾向于关注与我们正在处理的场景相关的领域模型的部分，尽管我们可能对更大的领域模型有总体的想法。如果您将Feature Injection与BDD一起使用，您将已经讨论了系统的大多数功能，尤其是新功能，因此您将了解该领域中的内容。进化和所有其他规则仍然适用。BDD和DDD配合得非常非常好，围绕场景的对话有助于引出领域语言。它们没有本质上的不同，但完全是相互支持和兼容的。
还请阅读我对这个类似问题的回答，其中有一段Dan North和我谈论这个话题的视频。
我会包括用户故事、DDD和BDD，因为它们彼此非常依赖。我试图在这里总结一下链接：http://christophelecoent.wordpress.com/2013/06/17/how-to-link-user-stories-ddd-and-bdd/
我希望这张图片既简单又丰富，足以解释这些"概念"