dav*_*004 11 bdd domain-driven-design
我对BDD的理解是,用户故事中描述了一个系统,然后开发人员将这些用户故事转化为一个应用程序,旨在为每个"sprint"(软件开发时期)增加真正的商业价值.结果(据我所知)是域模型在整个开发过程中从用户故事中浮现出来.也就是说,在第一次'sprint'之后,很多域模型都不会被设计出来.
我对DDD的理解是软件开发继续参考完整的域模型,尽管是一个不断发展的模型.在DDD中,模型预计会发生变化,但它始终是"完整的".
这似乎是两种方法之间的根本区别.人们如何处理这个问题？
Lun*_*ore 18
BDD做得好不会产生"完整"模型.有一个原因是,想出BDD的人Dan North称他的博客"充满了不确定性".
这些天我觉得有用的东西可以分析我们可以分析的三种东西:已知的,可知的和不可知的.
已知的东西很简单 - 例如,登录.这是很好理解的.我们不需要谈论这些场景.
可知的东西通常与域名或之前已经完成的事情有关.这是一个做BDD的好地方,因为它有助于将知识 - 包括域模型 - 从业务转移到开发人员.通过场景说话是更好地理解故事的好方法.它还可以帮助我们找到我们错过的场景.克里斯马特斯是帮助将"给定"放入"给定,何时,然后"的分析师,他称之为"破坏模型".他实际上为任何能够提出他的模型中没有涉及的场景的人提供奖品,他使用场景来定义和改进.
还有不可知的东西.每当我们处理一些新事物,或者我们以前从未做过的事情,或者没有人拥有专业知识的事情时,就会发生这种情况.你可以判断你是否在这个地方,因为当你想出他们没有想到的场景时,商人们会开始惊讶地做出反应.BDD是找到这些地方的一种非常好的方式,但此时你可能想要停止尝试确定方案,只是尝试一些东西并获得反馈.您的域模型,用户故事和场景将逐渐显现(请参阅Cynefin模型中的复杂域).
我知道很多团队使用BDD作为显然消除这种不确定性的一种方式.你不能消除它.你只能将它隐藏到以后,当交付的反馈回来咬你.
关于DDD,当我们使用BDD时,我们倾向于关注与我们正在处理的场景相关的域模型的那些部分,尽管我们可能已经了解了更大的域模型.如果您将功能注入与BDD一起使用,您已经已经讨论了系统的大部分功能,特别是新功能,因此您可以了解域中的内容.进化和所有其他规则仍然适用.BDD和DDD真的很好地协同工作,围绕有助于提出领域语言的场景进行对话.它们并没有根本不同,但完全支持和兼容.
另请阅读我给这个类似问题的答案,其中包含Dan North和我自己谈论这个话题的视频.