在领域驱动设计欧洲 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 倡导，每个人都了解领域。这就是复杂之处，不是在问题的技术层面上。因此，为了实现一个好的设计，提高敏捷性和价值，交付团队中的每个人都需要了解领域。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论