Domain driven design 行为驱动开发（BDD）如何与领域驱动设计（DDD）协同工作

我对BDD的理解是，一个人在用户故事中描述一个系统，然后开发人员将这些用户故事转化为一个应用程序，目的是在每个“冲刺”（软件开发阶段）中增加真正的业务价值。结果（据我所知）是，在整个开发过程中，域模型从用户故事中出现。也就是说，在第一次“冲刺”之后，许多领域模型将不会被设计

我对DDD的理解是，软件开发继续参考完整的领域模型，尽管这是一个不断发展的模型。在DDD中，模型预计会发生变化，但它始终是“完整的”

这似乎是两种方法之间的根本区别。人们是如何处理这个问题的？

BDD做得好并不能产生一个“完整”的模型。提出BDD的人Dan North给他的博客打电话是有原因的

我发现现在思考三种我们可以分析的东西是有用的：已知的、可知的和不可知的

已知的东西很简单-例如，登录。这很容易理解。我们不需要讨论这些场景

已知的东西通常与领域相关，或者与以前做过的事情相关。这是一个进行BDD的好地方，因为它有助于将知识（包括领域模型）从业务转移到开发人员。通过情景对话是更好地理解故事的好方法。它还可以帮助我们找到我们错过的场景。Chris Matts是帮助将“给定”放入“给定，何时，然后”的分析师，他称之为“打破模型”。事实上，他为任何能够提出他的模型中未包含的场景的人提供了奖励，他使用场景来定义和细化场景

还有一些不可知的东西。每当我们在做一些新的事情，或者我们以前从未做过的事情，或者没有人有专业知识的事情时，这种情况就会发生。你可以判断你是否在这里，因为当你提出他们没有想到的情景时，商务人士会开始感到惊讶。BDD是找到这些地方的一种非常好的方法，但在这一点上，您可能不想再试图确定场景，而只是尝试一些东西，然后获得反馈。您的域模型、用户故事和场景都将逐渐浮现（）

我知道很多团队使用BDD来消除这种不确定性。你不能消除它。你只能把它藏起来，直到稍后，当送货反馈回来咬你的时候

关于DDD，当我们使用BDD时，我们倾向于关注域模型中与我们正在处理的场景相关的部分，尽管我们可能对更大的域模型有一个总体的想法。如果您与BDD一起使用，您将已经讨论了系统的大部分功能，尤其是新功能，因此您将了解域中的内容。进化和所有其他规则仍然适用。BDD和DDD非常非常好地协同工作，围绕场景的对话有助于展示领域语言。它们没有本质上的区别，但完全支持和兼容

---

另请阅读，其中有一段Dan North和我谈论这个话题的视频。

我将包括用户故事、DDD和BDD，因为它们彼此非常依赖。我试图在这里总结链接：

---

我希望这张图片既简单又丰富，足以解释这些“概念”之间的联系。

我很高兴。以下是BDD教程幻灯片的链接，以防其他人感兴趣：