虽然行为驱动开发 (BDD) 更针对于会话和示例，但是 BDD 还有另外一面，就是软件设计部分。Konstantin Kudryashov 通过将 BDD 的会话部分和专注于领域的设计活动相结合，诠释了BDD 是如何用于领域驱动设计 (DDD) 的。
作为 BDD 实践经理， Kudryashov 描述了使用 BDD 书写用户故事中的场景的两种形式。命令式书写的用户故事从技术角度描述了应用将如何工作，通常会与实现相耦合；声明式书写的用户故事描述了问题和用户想达到的目的。他更喜欢后者。无论使用哪种形式书写，大多数 BDD 的实践者将停留在这个描述程度上，并将这些场景用于驱动实践，Kudryashov 相信这还远远不够，这种描述丢失了很多对业务非常重要的细节。通过与领域专家讨论，可以澄清命名、寻找丢失的关联信息等等。场景撰写可以包含更多细节，当使用业务人员和开发人员共享的通用的语言撰写时，通用语言 (ubiquitous language) 将会从中形成，这是 DDD 的核心概念之一。Kudryashov 宣称，通过这种方式撰写的场景将成为一种领域模型。
大力推动通用语言，就能够让示例成为领域模型
大多数 BDD 的实践者采用的测试方法是由外及内的方式，通过用户接口、界面来测试每个场景。与之相反，DDD 的实践者更针对领域核心，对他们来说关注点是隐藏在龟速而且脆弱的用户界面后面的，因此，他们趋向于工作在由内向外的方式下，从领域核心开发。直至其实现足够稳定，于核心之上实现的用户界面才会随之完成。为了强调这一点，Kudryashov 引用了 Vaughn Vernon 所著的《实现领域驱动设计》一书中的内容：
应用边界，或者内六边形也是用例（或者用户故事）的边界。换句话说，我们应当基于应用的功能性需求，而不是各种客户端或者输出装置的数量来创建用例。
为了将 BDD 和 DDD 实践放在一起，两种技术需要结合使用。为此，Kudryashov 首先去除了用户界面，然后通过领域来运行测试。从领域部分开始设计，与业务人员的对话就形成了架构师，针对问题领域进行不同的描述，将产生不同的架构，这种架构对于该领域来说更为自然。Kudryashov 发现这种方式的一个好处是去除持久层需求和前述场景中的用户界面，将大大缩减与领域专家会话的反馈循环，提高理解领域的速度。
使用这种方法，用户界面不再是应用的中心，而只是领域的一个控制器。只有用户界面是场景中的重要部分并且是应用所必需时才添加用户界面，而此时该领域早已被证明是可以工作的了。
在去年的一次演讲中，Ian Cooper 在讨论行为测试时使用过六边形架构。
查看英文原文： Behaviour-Driven Development Combined with Domain-Driven Design
感谢邵思华对本文的审校。
给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。
评论