我对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,其中有一个丹北的视频,我自己谈论这个话题.
