将BDD 与DDD 实践相结合

翻译自：Behaviour-Driven Development Combined with Domain-Driven Design

行为驱动开发（behavior Driven Development，BDD）在很大程度上是关于对话和示例的，但BDD的另一部分，即软件设计部分，Konstantin Kudryashov在研究如何将BDD与领域驱动设计（Domain Driven design，DDD）结合起来，将转换位与以领域为中心的设计活动结合起来时解释了这一点。

Kudryashov，作为BDD实践经理，描述了BDD中使用的两种用户故事编写场景样式；一种命令式样式，从技术角度描述了应用程序的工作方式，通常与实现相结合；另一种是声明式样式，他更喜欢这种样式，描述问题和用户想要实现的目标。无论使用何种风格，大多数BDD实践者都会停留在这个层次，使用这些场景来驱动实现，但Kudryashov认为这还不够，还缺少很多对业务很重要的细节。通过与领域专家交谈，澄清命名、寻找缺失的关系等，场景可以写得更详细，当用业务人员和开发人员共享的通用语言编写时，将出现一种无处不在的语言，这是DDD中的一个关键概念。通过这样编写场景，Kudryashov声称场景可以成为领域模型。

努力推动通用语言使你的例子成为一个领域模型。

对于大多数BDD从业者来说，方法是通过用户界面UI测试每一个场景，在外部进行测试。相反，DDD实践者最关心的是领域核心，对他们来说，领域核心隐藏在一个缓慢而脆弱的UI后面，因此他们倾向于从域核心开始，直到核心的实现足够稳定，才在核心之上实现UI。

强调一点，Kudryashov引用了沃恩·弗农（Vaughn Vernon）在其著作《实现领域驱动设计》（Implementing Domain Driven Design）中的话：

应用程序边界或内部六边形也是用例（或用户故事）边界。换句话说，我们应该基于应用程序功能需求创建用例，而不是基于不同客户端或输出机制的数量

为了将BDD和DDD实践结合起来，需要将这两种技术结合起来，Kudryashov首先删除UI，然后在领域中运行测试。从领域开始，与业务人员的对话就变成了架构师；根据用于描述问题域的词汇，不同的架构自然地出现在领域中。Kudryashov发现这样做的一个优点是，在显示工作场景之前，消除了持久性和UI的需求，在与领域专家的对话中，反馈循环大大缩短，从而大大加快了对领域的理解。

使用这种方法，UI不再是应用程序的中心，而只是领域的控制器。当用户界面被添加时，只有对用户界面至关重要的场景和应用程序是必需的，因为域已经被证明可以工作。

在去年的一次演讲中，伊恩库珀谈到了使用六边形架构时的行为测试。