将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 与DDD 实践相结合_第1张图片

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

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

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

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

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

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

 

 

 

你可能感兴趣的:(DDD)