是否可以同时使用DDD和BDD ?

我提供Dan North和我自己(请原谅头灯下的兔子，这是我的第一个视频)在BDD和DDD上接受Eric Evans的一位同事的采访。

你也可以预览一下我正在写的一本BDD书的第一章草稿的一部分(希望也是和Dan一起):

作为另一个效果，在没有任何技术术语的情况下，用业务语言讨论场景，允许开发人员选择该语言。然后，他们将该语言带入他们的代码库，实现以业务领域的元素命名的类，以这些元素的功能命名的方法，以及以其实际属性和子元素命名的属性和变量。

在Eric Evans的《领域驱动设计》一书中，这种业务术语在代码中的使用被称为通用语言。Eric建议，当开发人员开始使用与业务涉众术语相匹配的语言进行编码时，对话就会变得流畅，而不需要开发人员(或作为代理的分析师)在技术细节和领域概念之间来回转换。代码变得更易读，新手也更容易理解。系统中每个对象的价值变得更加明显，以及它将其价值提供给用户的路径，以便用户可以为业务提供价值。

JBehave引入了一些新的东西。不仅开发人员使用业务领域语言;他们现在使用一种业务人员能够理解的语言来描述软件术语。比起像test、验收测试、act、arrange、assert、红条和绿条这样的词，开发人员谈论的是示例、场景、上下文、事件、结果和行为。

JBehave和BDD已经为软件开发本身引入了一种通用的语言。

希望这表明BDD和DDD确实可以很好地协同工作。欢迎所有的反馈，除了我的穿着品味。

编辑:你说得对，这个域很坚固。这就是为什么我们关注更有风险的东西，比如表示和基础结构，并讨论我们对使用场景的领域的理解。我们不能得到关于我们对这个领域的理解的反馈，除非我们有一些东西可以通过得到反馈 -但这并不能阻止我们寻求理解。

让我补充一下我的答案，我绝不是BDD、TDD或测试优先专家。跑题了…

我发现所有测试优先的开发方法都需要水晶球级别的洞察力，当从零开始获得高水平的成功时。因为这是完全不切实际的，所以我发现这种级别的测试只有在核心DDD被充实的原型阶段之后才有意义。与其他核心架构决策一起，对于如何获得成功有一个清晰的思考过程。

作为一名企业架构师，我在项目开发中的首要思想总是可重复的成功。当核心架构在项目之间是一致的，甚至更重要的是在同一个项目中，这总是更容易实现的。

现在直接回答你的问题，在我的书中，DDD永远是第一位的。没有DDD，在我看来，当涉及到关键的架构设计决策时，你基本上是在黑暗中摸索，这可能会在以后变得非常痛苦。在我看来，DDD也是一个更高级的概念，它是用高级框图来表达的。使用许多BDD故事，这些故事将组成系统之间的DDD级交互。

关于我是否会为UI交互写故事的问题，它们肯定有价值。然而，由于项目约束总是比预期出现得更快，它们很容易被跳过，而代替了其他努力所需的时间。编写的编码UI测试不必是脆弱的。然而，如果他们是脆弱的，他们几乎没有目的开始。如果遵循HTML元素命名的明确约定，并编写语义HTML，就可以创建非常可靠的UI单元测试。这在MVC中比在asp.net中更容易表达。. NET, java可能有类似的并行)。

RE:你建议在实现故事之前创建域的刮擦?

我甚至会在定义模型类概念和服务接口方面做得更进一步。在开始实现接口的时候，就是我开始处理故事的时候。这也会导致模型或接口在出现时发生变化。让整个服务接口和模型在它们从故事演变而来的过程中进行设计，我觉得会产生太多的狭窄视野。您将开始制作解决特定故事的模型和/或接口，但对于更大的画面几乎没有意义。

总结一下你的中向外vs由外向内的问题。我觉得它们非常能够相互构建，如果你从DDD开始，从中找出整体概念，然后从外到内找出细节，就会更加如此。我觉得反过来做这个过程会导致更多不必要的重构，并且会导致更困难的重构，因为您将试图从最可能在筒仓中开发的相关故事的集合中拉出您的核心领域。

我很幸运在今年6月参加了Gojko Adzic的"实例说明"研讨会。

Gojko在课堂上提到了Eric Evans和DDD。

对我来说，灵光一闪的时刻是当我们正在做的练习引导我们重构领域模型以"获得更深入的知识"时，也就是说，当我们获得对领域的更深入的洞察时，我们重构了模型，并使用BDD测试来反映这种洞察。

课程中的例子是《21点》游戏，我们最初将一手牌建模为基于牌总数的整数值。随着我们对21点游戏的运作方式有了更深入的了解，我们引入了"21点"手牌的概念，因此不再使用整数值来表示手牌，而是使用整数值或"21点"手牌。

在我的实践中，我寻求发展领域模型和它的通用语言。然后，我在我的BDD测试中使用这种通用语言。

我不明白为什么它不应该工作?BDD是行为驱动的开发，也就是说，关于您的开发过程，它可能(应该)影响您的设计。DDD是领域驱动的设计，更多的是关于系统的总体设计。长话短说，在BDD(或任何其他xDD)中，您定义了某些东西应该如何工作，然后由您的领域来实现这些需求。如果您使用DDD或其他不重要的东西来实现这些需求……你仍然需要一个绿色的标记旁边的测试。

UPDATE:我不认为DDD是关于方向，对我来说DDD是关于保持你的代码干净。我想说的是，使用BDD是一种帮助保持代码整洁的方法，如果您一开始只是实现您的域，那么最终可能会得到一个过于复杂的域。我想使用BDD来定义我的特性(如登录功能)和不同的场景(如成功登录和不成功登录)。在那之后，我不会写一些单元测试，所以我有一些测试代码而不是行为的东西。当我实现了单元测试通过后，希望BDD测试也能通过。之后就是重构的时候了，在重构过程中，所有的测试都应该保持绿色。您可以将其视为两个循环，一个测试行为(BDD)的外部循环和一个测试实现(TDD)的内部循环。这应该而不是阻止你使用DDD原则，相反，我想说它会让你更容易保持你的领域干净，并解决你手头的实际问题。

更新2(链接):

• mvcConf(在线会议)关于BDD与TDD结合的介绍:http://channel9.msdn.com/Series/mvcConf/mvcConf-2-Brandom-Satrom-BDD-in-ASPNET-MVC-using-SpecFlow-WatiN-and-WatiN-Test-Helpers
• QCon关于BDD和DDD的演讲，http://www.infoq.com/presentations/bdd-and-ddd。我自己还没见过，但看起来很有希望。

是的，我相信BDD和DDD可以一起使用。这里有一个c#测试框架，可以帮助实现这个

http://kernowcode.github。io/UBADDAS/

总之:是的，特别是在知识处理中，我们可以使用BDD和DDD工具来获得更好的模型，正如你可能知道的，每个工具都可能有一些盲点和错误;我通常同时使用事件风暴和示例映射。这种方法将帮助我们获得更好的UL。