DDD的价值
本文是对自己使用DDD的总结,重点不是告诉到家什么是DDD,怎么是DDD,重点是应该在什么样的场景使用并发挥它的最大价值。
在说价值之前,先说说目前的开发模式。
1 产品侧刻画用户故事;
2 开发侧开始进行库表设计并开始叠加代码;

这种模式也就是目前的敏捷开发,在开发的初期,非常的高效,原因是系统的复杂度不高,也是离散程度不好,熵增不大。

但随着项目快速迭代,大量的交叉点出现,系统的复杂性逐渐提高,此时随着项目的控制以及增加人力,还能勉强支撑,对原有系统进行打补丁。

等到敏捷开发的后期,已经很难靠人力维持系统的迭代,随着人员的变动,将导致本来留在领域内的知识丢失,最终将变成一团乱麻。即使有通过人力成本,对原有逻辑梳理都是一个很大的问题,此时对与这种问题的解决方案是另起炉灶,而另起炉灶虽然能解决短痛,但随着业务叠加,与老系统打通时是一个很痛苦甚至是一个无法打通的过程。
- 
迭代难,演进难,维护难 会是敏捷后期不可避免的痛。
原因是敏捷开发变成了项目管理者的管理工具,不注重模型沉淀,一味的追求迭代速度,有的管理者甚至认为沉淀模型是浪费人力资源。
针对敏捷开发的后期痛点,DDD是如何解决的?DDD是将系统复杂性从无序治理成有序的一种方案。
- 
1、强调模型价值,将产品侧的心智模型、开发侧的数据模型统一为领域模型(领域模型,是针对特定领域里的关键事物及其关系的可视化表现,是为了准确定义需要解决问题而构造的抽象模型,是业务功能场景在软件系统里的映射转化,其目的是为软件系统构建统一的认知)。

2、强调演绎,将复杂的问题划分可执行的子问题。
3、强调归纳,具有相关业务属性的放在一起处理。
4、强调边界,每个领域处理属于自己领域的事情。
5、强调统一语言,就像最终代码是由产品自己写的一样。
6、强调沉淀,在业务进行到特定时候,对模型进行归纳,抽象,为后续支撑更复杂业务做准备。

DDD是一种有效控制墒增的一个解决方案。随着业务越做越多,模型越来越健壮,支撑能力越强,通过模型对共性抽取,通过拓展点对特性实现,随着通用语言管理,自动维护系统大图,完美的将敏捷开发后期的软肋转化为优点。信人可以迅速了解原有业务,老员工可以根据领域模型快速做系统的迭代。
- 