我喜欢使用 DDD 实现的中间开发。开发由领域驱动，领域是应用程序中最可靠的部分。我们不依赖于基础设施、持久性和演示。这听起来不错。但它没有商业价值。
这里出现了以业务为中心的BDD，由外而内的发展。我们没有前期的域设计（选择实体、值对象、聚合）。我们采用用户故事，编写一些场景并逐个实现它们。我们从应用程序最可变的部分开始开发 - 从演示开始。我讨厌写脆弱的验收测试。是吗？
因此，如果这里有人有关于以BDD风格应用DDD的成功案例，请与我分享一些:)
任何帮助将不胜感激。谢谢！
我邀请Dan North和我自己（请原谅车灯里的兔子，这是我的第一个视频）接受Eric Evans的一位同事在BDD和DDD上的采访。
此外，您还可以先睹为快地预览我正在写的BDD书中第一章草稿的一部分（希望与Dan一起）：
作为另一个效果，用商业语言在没有任何技术词汇的情况下讨论场景，允许开发人员选择该语言。然后，他们将该语言带入其代码库，实现以业务域元素命名的类，以这些元素的功能命名的方法，以及以其实际属性和子元素命名的属性和变量。
在代码中使用业务术语被称为Eric Evans的书“领域驱动设计”中无处不在的语言。Eric建议，当开发人员开始使用与业务利益相关者的术语相匹配的语言进行编码时，对话就会变得流畅，而不需要开发人员（或分析师作为代理）从技术细节到领域概念来回翻译。代码变得更具可读性，更易于新手理解。系统中每个对象的值变得更加明显，以及它向用户提供其值的路径，以便用户可以为业务提供价值。
JBehave引入了一些新的东西。开发人员不仅使用业务域语言;他们现在使用一种企业可以理解的语言来描述软件术语。开发人员谈论的不是测试、验收测试、行动、安排、断言、红条和绿条等词，而是示例、场景、上下文、事件、结果和行为。
JBehave和BDD为软件开发本身引入了一种无处不在的语言。
希望这表明BDD和DDD确实可以很好地协同工作。欢迎所有反馈，除了我的着装感。
编辑：你是对的，域名非常可靠。这就是为什么我们专注于风险更高的东西，如演示和基础结构，并谈论我们使用场景对域的理解。在我们有一些东西可以获得反馈之前，我们无法获得有关我们对该领域的理解的反馈 - 但这并不能阻止我们寻求理解。
让我在我的答案中添加前身，即我绝不是BDD，TDD或测试第一专家。题外话...
我发现所有测试优先的开发方法都需要水晶球级的透视预感，从头开始才能取得高水平的成功。由于这是完全不切实际的，我发现这种级别的测试只有在核心DDD被充实的原型设计阶段之后才有意义。与其他核心架构决策一起到位，关于如何取得成功有一个清晰的思维过程。
作为一名企业架构师，我在项目开发中的#1想法总是可重复的成功。当核心架构在项目之间保持一致时，这总是更容易实现，更重要的是在同一项目中也是如此。
现在直接回答你的问题，在我的书中，DDD总是会排在第一位。如果没有DDD，我认为当涉及到关键的架构设计决策时，你基本上是在黑暗中刺伤，这些决策以后可能会变得非常痛苦。在我看来，DDD也是一个更高级的概念，它以高级框图表示。有许多BDD故事，这些故事将构成系统之间的DDD级交互。
关于我是否会为UI交互编写故事的问题，它们肯定有价值。然而，它们很容易被跳过，而不是其他工作所需的时间，因为项目限制往往总是比预期的更早出现。您编写的编码 UI 测试不必脆弱。但是，如果它们很脆弱，那么它们一开始就几乎是无目的的。如果您遵循明确的 HTML 元素命名约定，以及编写语义 HTML，则可以创建非常可靠的 UI 单元测试。与webforms相比，这在MVC中更容易表达（ASP.NET，java可能具有某种类似的并行性）。
RE：你建议在实现故事之前创建域名的划痕？
我甚至通常会在定义模型类概念和服务接口方面走得更远。当接口的实现开始时，我就开始处理故事了。这也会导致模型或接口发生变化。如果把整个服务接口和模型设计得像故事一样，我觉得会产生太多的隧道视野。您将开始制作解决特定故事的模型和/或界面，但对于更大的图景几乎没有意义。
因此，要真正总结一下你的中间偏外问题，而不是由外而内的问题。我觉得他们非常有能力相互构建，如果你从DDD中间开始整体概念，然后从外到内地工作细节，那就更是如此。我觉得反向执行该过程将导致比必要的更多的重构，并且重构更加困难，因为您将尝试将核心领域从最有可能在孤岛中开发的相关故事的集合中拉出来。
