我喜欢用DDD实现的中间开发。开发是由域，应用程序中最可靠的部分驱动的。我们不依赖于基础设施，持久性和演示。听起来不错。但它没有商业价值。
这是以业务为中心的BDD，具有从外到内的开发。我们没有前期域设计（选择实体，值对象，聚合）。我们收集用户故事，编写一些场景并逐个实现。我们从应用程序的最多变的部分开始开发 - 从演示。我讨厌写脆弱的验收测试。你呢？
所以，如果有人在这里有关于在BDD风格中应用DDD的成功故事，请与我分享：）
任何帮助将不胜感激。谢谢！
答案 0 :(得分：20)
我提供Dan North and myself（请原谅前照灯中的兔子，这是我的第一个视频）正在接受Eric Evans的一位BDD和DDD同事的采访。
此外，您可以从我正在撰写的BDD书籍中预览第一章草案的一部分（希望与Dan一起）：
另一种效果是，在商业语言中讨论没有任何技术词汇的场景，允许开发人员选择该语言。然后，他们将该语言带入他们的代码库，实现以业务域元素命名的类，以这些元素的功能命名的方法，以及以其真实属性和子元素命名的属性和变量。
在代码中使用业务术语在Eric Evans的书“Domain Driven Design”中被称为无所不在的语言。 Eric建议，当开发人员开始使用与业务利益相关者的术语相匹配的语言编写代码时，会话变得流畅，而不需要开发人员（或分析师作为代理）来回转换从技术细节到域概念。代码变得更易读，更容易让新手理解。系统中每个对象的值变得更加明显，以及它向用户提供其价值的路径，以便用户可以为业务提供价值。
JBehave介绍了一些新东西。开发人员不仅使用业务领域语言;他们现在使用业务所理解的语言来描述软件术语。而不是像 test ，验收测试，行为，安排，断言这样的词，开发人员正在讨论示例，场景，上下文 ，事件，结果和行为。
JBehave和BDD为软件开发本身引入了一种无处不在的语言。
希望这表明BDD和DDD确实很好地协同工作。欢迎所有反馈，除了我的着装感。
编辑：你是对的，域名非常可靠。这就是为什么我们专注于更具风险的东西，如演示和基础设施，并谈论我们使用场景对域的理解。在我们得到 的反馈意见之前，我们无法获得对域名理解的反馈 - 但这并不能阻止我们寻求理解。
答案 1 :(得分：7)
让我在答案中添加前提，我绝不是BDD，TDD或测试第一专家。弃土......
我发现所有测试的第一个开发方法都要求从头开始获得高水平的成功时的水晶球水平透视预感。由于这是完全不切实际的，我发现这个级别的测试只有在核心DDD已经充实的原型设计阶段之后才有意义。与其他核心架构决策一起，确定了如何取得成功的明确思考过程。
作为企业架构师，我在项目开发中的第一个想法总是可以重复成功。当核心架构在项目之间保持一致时，这一点总是更容易实现，更重要的是在同一个项目中也是如此。
现在直接回答你的问题，在我的书中，DDD总是先来。如果没有DDD，我认为在关键架构设计决策方面，你基本上是在黑暗中刺伤，这可能会在以后变得非常痛苦。在我看来，DDD更像是一个更高层次的概念，它以高级框图表示。许多BDD故事将包含系统之间的DDD级别交互。
关于我是否会为UI互动编写故事的问题，它们肯定有价值。然而，由于项目限制往往比预期更早出现，因此很容易被忽略以代替其他努力所需的时间。您编写的编码UI测试不一定非常脆弱。但是，如果它们很脆弱，那么它们几乎是无目的的。如果您遵循HTML元素命名的明确约定，并且编写语义HTML，您可以创建非常可靠的UI单元测试。这更容易在MVC中表达，而不是webforms（在ASP.NET中，java可能有某种类似的并行）。
RE：您建议在实施故事之前创建域名划痕？
我甚至可以更进一步地定义Model类概念和服务接口。那时接口的实现开始就是我开始处理这些故事的时候。这也会导致模型或接口出现变化。为了让整个服务界面和模型在故事发展过程中设计出来，我觉得会产生太多的隧道视野。您将开始制作解决特定故事的模型和/或界面，但对整体情况几乎没有任何意义。
所以要真正总结一下你的中后卫和外线的问题。我觉得他们非常有能力相互建立，如果你从DDD中间开始为整体概念开始，那么更多，然后从外到外工作以获取细节。我觉得反过来做这个过程会导致更多的重构而不是必要的，而且更加艰难的重构，因为你试图从一系列相关故事中抽出你的核心领域，而这些故事很可能是在一个孤岛中开发的。
答案 2 :(得分：5)
我很幸运能够在今年6月份参加Gojko Adzic的“典型规范”研讨会。
Gojko在整个班级中提到了Eric Evans和DDD。
对我而言，灯泡时刻就是当我们进行的练习引导我们重构领域模型'以获得更深层次的知识'时，也就是说，当我们对领域有更深入的了解时，我们重构了模型并用它来重构BDD测试反映这种见解。
班上的例子是一个二十一点游戏，我们最初根据牌的总和将一手牌建模为整数值。随着我们对二十一点游戏如何运作的深入理解，我们引入了一只手是“二十一点”手的概念，因此不再使用整数值来表示手是整数值还是'二十一点'手。
在我的实践中，我寻求发展领域模型及其无处不在的语言。然后我在BDD测试中使用这种无处不在的语言。
答案 3 :(得分：1)
我看不出它为什么不起作用？ BDD是行为驱动的开发，即在您的开发过程中，这可能（应该）影响您的设计。 DDD是域驱动设计，更多的是关于系统的整体设计。总而言之，在BDD（或任何其他xDD）中，您可以定义某些内容应该如何工作，然后由您的域来实现这些要求。如果你使用DDD实现这些要求或其他什么不重要......你仍然需要在该测试旁边带一个绿色标记。
更新：我不认为DDD是关于方向的，对我来说DDD就是要保持代码清洁。我会说使用BDD是一种帮助保持代码清洁的方法，如果你开始只是实现你的域，你最终可能会得到一个太复杂的域。我想这样做的方法是使用BDD来定义我的功能（如登录功能）和不同的场景（如成功和不成功登录）。之后我不会写一些单元测试所以我有一些测试代码而不是行为。当我实施时，单元测试也有希望通过BDD测试通过。之后是重构的时间，在重构期间，所有测试都应该保持绿色。您可以将其视为两个周期，一个测试行为的外循环（BDD）和一个测试实现的内圈（TDD）。这应该不阻止您使用DDD原则，相反我会说这样可以更轻松地保持您的域清洁并解决您手头的实际问题。
更新2（链接）：
答案 4 :(得分：0)
是的，我相信BDD和DDD可以用来代替。这是一个可能有助于实现此目的的C＃测试框架