可以同时使用DDD和BDD吗？

Question

我喜欢用DDD实现的中间开发。开发是由领域驱动的，领域是应用程序中最牢固的部分。我们不依赖基础架构，持久性和表示方式。听起来不错。但是它没有商业价值。

这里有以业务为中心的BDD和外部开发。我们没有前期领域设计（选择实体，值对象，集合）。我们以用户故事为例，编写一些方案并逐一实施。我们从应用程序最可变的部分开始开发-
从演示开始。我讨厌编写脆弱的验收测试。你呢？

因此，如果这里有人成功应用BDD风格的DDD的故事，请与我分享：)

1. 您是否编写那些脆弱的测试以进行演示？
2. 在为实现的用户故事创建域的一部分之前，您是否有一些前期设计？还是在实现故事后就重构为DDD模式？

任何帮助将不胜感激。谢谢！

Answer 1

我提供了DanNorth和我本人（请原谅我的大灯，这是我的第一个视频，这是我的第一个视频）Dan

您也可以从我正在撰写的BDD书中预览第一章草案的一部分（也很希望与Dan在一起）：

另一个效果是，用商务语言讨论不带任何技术词汇的方案，使开发人员可以选择该语言。然后，他们将该语言带入他们的代码库，实现以业务领域的元素命名的类，以这些元素的功能命名的方法以及以其实际属性和子元素命名的属性和变量。

业务术语在代码中的这种使用在Eric Evans的书“域驱动设计”中被称为 无处不在的语言
。埃里克（Eric）建议，当开发人员开始使用与业务利益相关者的术语相匹配的语言进行编码时，对话变得流畅起来，而无需开发人员（或分析师作为代理）将技术细节来回转换为领域概念。该代码变得更具可读性，并且新手也更容易理解。系统中每个对象的价值以及其将价值返回给用户的路径变得更加明显，以便用户可以为企业提供价值。

JBehave引入了一些新东西。开发人员不仅在使用业务领域语言；他们现在使用的是企业可以理解的语言来描述软件术语。开发人员正在谈论 示例 ，
场景 ， 上下文 ， 事件 ， 结果 和 行为 ，而不是诸如 测试 ， 验收测试 ， 行动 ， 安排 ， 断言
， 红色条 和 绿色条之类的词 。

JBehave和BDD已经为软件开发本身引入了无处不在的语言。

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

编辑：您是对的，该域非常可靠。这就是为什么我们专注于诸如演示文稿和基础架构之类的风险更高的东西，并谈论我们使用场景对领域的理解。直到我们有一些要获得反馈的信息时
， 我们才能获得对我们对域的理解的反馈 ， 但是无论如何这并不能阻止我们寻求对该域的理解。