Paul Rayner认为DDD和敏捷可以共存

DDD 敏捷 瀑布

摘要

领域驱动设计对敏捷实践而言是一个很好的补充，它可以避免“瀑布式设计方法”，从而避免最坏的设计：无设计。

正文

在领域驱动设计欧洲2016大会上，Paul Rayner在演讲中提出将领域驱动设计（DDD）引入敏捷软件交付过程。他将敏捷视为一种组织工作的方法，而不是一种界定工作方式的规定。他认为敏捷参与者经常不够重视设计，建议使用DDD概念作为一种克服这些缺点的方式。更进一步，Rayner认为，敏捷与DDD的结合可以加速软件交付。

在从事顾问工作的过程中，Rayner见过许多践行敏捷的团队强调MVP（最小可行产品）的重要性以致损害了设计。他引用了Douglas Martin关于设计必然性的观点：“好设计的替代品是坏设计，而不是完全无设计。”避免瀑布方法中的“大量提前设计”，只做最低限度的工作，这些团队最终获得了坏设计。实际上，敏捷宣言宣称，“不断关注优秀的技能和好的设计会增强敏捷能力”。敏捷的目的不只是速度，而是敏捷性。好的设计可以实现敏捷性。这实际上就是设计的目的，Rayner援引Venkat Subramaniam的话对此进行了佐证：“好的设计不是正确地预测了未来的设计，而是让适应未来的成本不那么高昂的设计。”

他指出，设计基本上是迭代的，这样一来就很容易包含到敏捷中。设计是一个发现未知并简洁地表达复杂观点的过程。由于你永远无法提前知道所有的一切，所以设计必然会随着时间变化。花些时间用来发现，并在交付的代码中表达新知识，这样会节省后续过程的时间，因为代码本身变得更加敏捷了。一种方法是“旋涡模式探索过程（whirlpool process of model exploration）”。在这个过程中，你反复使用新场景挑战已有的领域模型，提出新模型，并编写代码实现它。

Rayner还列出了其他一些敏捷团队使用过的、从DDD的视角来看经常失败的方法。一个是认为不断地重构为好的设计已经够了。这可能会实现清理代码的效果，但DDD强调引入新概念。这些新概念不是从代码中出现的，因此无法仅仅通过重构创建出来，而是要在业务建模中形成。它们会增加业务价值，而重构，根据定义，并不改变软件的功能。

Rayner提到，在Scrum中，一个定义好的“产品经理”角色很容易让团队中的其他人将其视为所有业务需求/知识的唯一中转。DDD倡导，每个人都了解领域。这就是复杂之处，不是在问题的技术层面上。因此，为了实现一个好的设计，提高敏捷性和价值，交付团队中的每个人都需要了解领域。

查看英文原文：Paul Rayner Says DDD and Agile Can Coexist