域驱动设计 – 行为驱动开发(BDD)如何与域驱动设计(DDD)协同工作

我对BDD的理解是描述用户故事中的系统,然后开发人员将这些用户故事转化为应用程序,旨在为每个“sprint”(软件开发期)增加真正的商业价值.结果(据我所知),在整个开发过程中,域模型来自用户故事.也就是说,在第一个“冲刺”之后,大部分领域模型将不会被设计.

我对DDD的理解是,软件开发继续参考完整的域模型,尽管是一个不断发展的模式.在DDD中,模型预计会发生变化,但始终是“完整”的.

这似乎是两种方法的根本区别.人们怎么处理这个？

这些天我觉得有用,想到可以分析的三种东西：已知的,可知的和不可知的.

已知的东西很简单 – 例如登录.很好理解.我们不需要通过这些场景进行交流.

可知的东西通常与域相关,或者与之前已经做过的事情有关.这是BDD的好地方,因为它有助于将知识(包括领域模型)从业务转移到开发人员.通过情景说话是更好地了解故事的好方法.它也可以帮助我们找到我们错过的方案.分析师克里斯·马特斯(Chris Matts)帮助把“给定的时间”放在“给定的时刻”中,称之为“打破模范”.他实际上为任何可以提出他的模型中没有涵盖的场景的人提供奖品,他使用场景来定义和改进.

还有不可知的东西.当我们正在开发新的东西,或者我们从未做过的事情,或者没有人拥有专业知识的时候,就会发生这种情况.你可以告诉你是否在这个地方,因为当你想出了他们没有想到的情景时,商界人士会开始反应惊喜. BDD是找到这些地方的一个非常好的方法,但在这一点上,您可能想要停止尝试确定场景,只是尝试一些东西并获得反馈.您的域名模型,您的用户故事和您的场景将逐渐显现(see the complex domain in the Cynefin model).

我知道很多团队使用BDD作为显然消除这种不确定性的一种方式.你不能消除它.你只能隐藏它,直到后来,当交付的反馈回来咬你.

对于DDD,当我们使用BDD进行处理时,我们倾向于关注与我们正在开发的方案相关的领域模型的那些部分,尽管我们可能会对整体的更大的域模型有一个想法.如果您与BDD一起使用Feature Injection,您将已经了解了系统的大部分功能,特别是新的功能,因此您可以了解域中的哪些内容.进化和所有其他规则仍然适用. BDD和DDD的工作真的很好,在一起,围绕有助于展示域语言的场景的对话.它们根本不同,但完全支持和兼容.

还请阅读the answer I gave to this similar question,其中有一个丹北的视频,我自己谈论这个话题.

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!