我对BDD的理解是，用户故事中描述了一个系统，然后开发人员将这些用户故事转换为应用程序，旨在为每个“sprint”（软件开发时期）添加真正的业务价值。结果（据我所知）是域模型在整个开发过程中从用户故事中出现。也就是说，在第一次'sprint'之后，很多域模型都不会被设计出来。
我对DDD的理解是软件开发继续参考完整的域模型，尽管是一个不断发展的模型。在DDD中，模型预计会发生变化，但它始终是“完整的”。
这似乎是两种方法之间的根本区别。人们如何处理这个？
答案 0 :(得分：18)
BDD做得好不产生“完整”模型。提出BDD的人Dan North打电话给他的博客"embracing uncertainty"。
我觉得这些日子我们可以分析三种我们可以分析的事情：已知的，可知的和不可知的。
已知的东西很简单 - 例如，登录。很好理解。我们不需要谈论这些场景。
可知的东西通常与域有关，或者与之前已经完成的事情有关。这是一个做BDD的好地方，因为它有助于将知识 - 包括域模型 - 从业务转移到开发人员。通过场景说话是更好地理解故事的好方法。它还可以帮助我们找到我们错过的场景。克里斯马特斯是帮助将“给定”放入“给定，何时，然后”的分析师，他称之为“破坏模型”。他实际上为那些能够提出他的模型中未涉及的场景的人提供了奖品，他使用场景来定义和改进。
还有不可知的东西。每当我们处理一些新事物，或者我们以前从未做过的事情，或者没有人拥有专业知识的事情时，就会发生这种情况。你可以判断你是否在这个地方，因为当你想出他们没有想到的场景时，商人们会开始惊讶地做出反应。 BDD是找到这些地方的一种非常好的方式，但此时你可能想要停止尝试确定方案，只是尝试一些东西并获得反馈。您的域模型，用户素材和场景都将逐渐显现（see the complex domain in the Cynefin model）。
我知道很多团队使用BDD作为显然消除这种不确定性的一种方式。你不能消除它。你只能将它隐藏到以后，当交付的反馈回来咬你时。
关于DDD，当我们使用BDD时，我们倾向于关注与我们正在处理的场景相关的域模型的部分，尽管我们可能有一个想法总体上更大的域模型如果您将Feature Injection与BDD一起使用，那么您已经已经讨论了系统的大部分功能，特别是新功能，因此您可以了解域中的内容。进化和所有其他规则仍然适用。 BDD和DDD真的很好地协同工作，围绕有助于提出领域语言的场景进行对话。它们并没有根本不同，但完全支持和兼容。
另请阅读the answer I gave to this similar question，其中包含Dan North的视频，我自己也在谈论这个主题。
答案 1 :(得分：3)
我会包含用户故事，DDD和BDD，因为他们非常非常依赖彼此。我试着总结一下这里的链接：http://christophelecoent.wordpress.com/2013/06/17/how-to-link-user-stories-ddd-and-bdd/
我希望这张照片既简单又丰富，足以解释这些“概念”之间的联系