本文探讨了DDD（领域驱动设计）如何缓解敏捷开发后期的复杂性问题。传统的敏捷开发模式在项目初期高效，但随着迭代增加，系统复杂度上升，导致维护困难。DDD强调模型价值、领域模型、演绎、归纳、边界和统一语言，通过这些原则将无序变为有序，控制系统的熵增。它提倡在业务发展过程中不断沉淀和抽象模型，以应对日益复杂的业务需求，使得新成员能更快理解业务，老员工能更高效地进行系统迭代。
DDD的价值
本文是对自己使用DDD的总结，重点不是告诉到家什么是DDD，怎么是DDD，重点是应该在什么样的场景使用并发挥它的最大价值。
在说价值之前，先说说目前的开发模式。
1 产品侧刻画用户故事；
2 开发侧开始进行库表设计并开始叠加代码；
这种模式也就是目前的敏捷开发，在开发的初期，非常的高效，原因是系统的复杂度不高，也是离散程度不好，熵增不大。
但随着项目快速迭代，大量的交叉点出现，系统的复杂性逐渐提高，此时随着项目的控制以及增加人力，还能勉强支撑，对原有系统进行打补丁。
等到敏捷开发的后期，已经很难靠人力维持系统的迭代，随着人员的变动，将导致本来留在领域内的知识丢失，最终将变成一团乱麻。即使有通过人力成本，对原有逻辑梳理都是一个很大的问题，此时对与这种问题的解决方案是另起炉灶，而另起炉灶虽然能解决短痛，但随着业务叠加，与老系统打通时是一个很痛苦甚至是一个无法打通的过程。
- 
迭代难，演进难，维护难 会是敏捷后期不可避免的痛。
原因是敏捷开发变成了项目管理者的管理工具，不注重模型沉淀，一味的追求迭代速度，有的管理者甚至认为沉淀模型是浪费人力资源。
针对敏捷开发的后期痛点，DDD是如何解决的？DDD是将系统复杂性从无序治理成有序的一种方案。
- 
1、强调模型价值，将产品侧的心智模型、开发侧的数据模型统一为领域模型（领域模型，是针对特定领域里的关键事物及其关系的可视化表现，是为了准确定义需要解决问题而构造的抽象模型，是业务功能场景在软件系统里的映射转化，其目的是为软件系统构建统一的认知）。
2、强调演绎，将复杂的问题划分可执行的子问题。
3、强调归纳，具有相关业务属性的放在一起处理。
4、强调边界，每个领域处理属于自己领域的事情。
5、强调统一语言，就像最终代码是由产品自己写的一样。
6、强调沉淀，在业务进行到特定时候，对模型进行归纳，抽象，为后续支撑更复杂业务做准备。
DDD是一种有效控制墒增的一个解决方案。随着业务越做越多，模型越来越健壮，支撑能力越强，通过模型对共性抽取，通过拓展点对特性实现，随着通用语言管理，自动维护系统大图，完美的将敏捷开发后期的软肋转化为优点。信人可以迅速了解原有业务，老员工可以根据领域模型快速做系统的迭代。
- 
扫一扫
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
