行为驱动开发与领域驱动设计相结合

infoq

原文：http://www.infoq.com/news/2015/02/bdd-ddd

摘要

虽然行为驱动开发(BDD)更针对于会话和示例，但是其软件设计部分可以用于领域驱动设计(DDD)的实践，Konstantin Kudryashov诠释了BDD的会话部分和领域设计活动的结合运用。

虽然行为驱动开发(BDD)更针对于会话和示例，但是BDD还有另外一面，就是软件设计部分。Konstantin Kudryashov诠释了BDD是如何用于领域驱动设计(DDD)，将BDD的会话部分和领域设计活动相结合的。

Kudryashov作为BDD实践管理者，描述了使用BDD书写用户故事的两种形式。命令式书写的用户故事从技术角度描述了应用将如何工作，通常会与实现相耦合；声明式书写的用户故事描述了问题和用户想达到的目的。他更喜欢后者。无论使用哪种形式书写，大多数BDD的实践者将停留在这个描述程度上，并将这些场景用于驱动实践，Kudryashov相信这还远远不够，描述丢失了很多对业务非常重要的细节。通过与领域专家讨论，可以澄清命名、寻找丢失的相关信息等等，场景撰写可以使用更多细节，当使用业务人员和开发人员共享的普通语言撰写时，通用语言(ubiquitous language)将会从中形成，这是DDD的核心概念。Kudryashov宣称，通过这种方式撰写的场景将成为一种领域模型。

推动通用语言不足以让示例成为领域模型

大多数BDD的实践者采用的测试方法是由外及内的方式，通过用户接口、界面来测试每个场景。与之相反，DDD的实践者更针对领域核心，对他们来说关注点是隐藏在龟速而且脆弱的用户界面后面的，因此，他们趋向于工作在由心向外的方式下，开始于领域核心直至其实现足够稳定，于核心之上实现用户界面随之完成。为了强调这一点，Kudryashov引用了Vaughn Vernon所著的《实现领域驱动设计》一书中的内容：

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

为了将BDD和DDD实践放在一起，两种技术需要合并。为此，Kudryashov首先去除了用户界面，然后通过领域来运行测试。
架构师与业务人员使用领域会话，从自然语言变成领域语言，不同的问题领域描述将产生不同的架构。Kudryashov发现这种方式的一个好处是去除持久层需求和前述场景中的用户界面，将大大缩减与领域专家会话的反馈时间，提高理解领域的速度。

使用这种方法，应用的中心不再是用户界面而只是领域的控制器。只有用户界面是场景中的重要部分并且是应用所必需时才添加用户界面，而此时应用早已被证明是可以工作的了。

In a presentation last year Ian Cooper talked about testing of behaviour when using the Hexagonal Architecture.

在去年的一次演讲中，Ian Cooper在讨论行为测试时使用过六边形架构。