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