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