DDD系列-背景
2022-10-15 23:16:49    31    0    0
weibo-007

DDD系列-背景

其实笔者认为,在软件的发展过程中,业务价值始终是排在第一位的,笔者之前所在的公司一直是敏捷开发模式,问题也基本上朝着单体应用的毛病一步一步演进,但是在期间也创造了大量的业务价值。在演进的过程中,会出现各种问题,更高级的开发模式往往能解决更多的问题,但是这并不大表越高级越好,适合当前业务的模式才是最好的开发模式。

瀑布流开发模式

模式介绍

软件设计有不同的方法,其中之一是瀑布设计法。这种方法包含了一些阶段,业务专家提出一堆需求同业务分析人员进行交流,分析人员基于那些需求来创建模型并将结果传递给开发人员,开发人员根据他们收到的内容开始编码。瀑布设计法中知识只有单一的流向。这种传统方法虽然应用很多年,但是还是有一定的缺陷和局限。主要是业务专家得不到分析人员的反馈信息,分析人员也得不到开发人员的反馈信息。

 

假设要做一个在线售卖机系统,那这个售卖机所有的用例集合起来称为需求,然后严格按照需求-设计-开发-测试一次性搞定。

有的人可能会有疑问,我们现在不就是这样开发的吗,注意,这里的需求不同于我们平时PM说的需求,PM层面的需求是一个一个用例,这里的需求是所有的用例集合。

整个过程可以用下图描述

主要缺点

这种方式的主要缺点是周期长,没有反馈闭环,项目失败的风险极高。而且,这种方式一开始就确定了所有需求,考虑面面俱到,但是这所有的需求中大部分的需求

都没有机会使用。这种方式的项目大部分以失败告终。

主要优点

但是,有一些场景必须用瀑布流开发模式,比如航天飞机,摩天大楼这些中途一旦变更需求,将会造成巨大的成本,所以肯定是需求阶段就已经面面俱到了。

敏捷开发模式

模式介绍

由于瀑布流开发模式失败率太高,另一个方法是敏捷方法学,这些方法不同于瀑布方法的一堆动作,产生背景是预先很难确定所有的需求,特别是需求经常变化的情况。敏捷开发试图解决另一个问题被称为"分析瘫痪",团队成员会因为害怕做出任何设计决定而无济于事。敏捷开发者反对预先设计,相反,他们应用大量的灵活设计。在敏捷设计者的眼中,他们崇尚,天下武功,唯快不破。

还是用售卖机为例子,那这个售卖机中的一个支付支持作为一个需求,就仅仅这一个需求在敏捷者的眼里,也不会一次性开发完成,而是周期迭代方式进行。

敏捷开发的优点非常多,比如团队协作,项目风险控制,市场验证,非常适合创新项目,也是现在很多公司主流的开发模式

主要缺点

敏捷开发也有自己的不足,敏捷开发缺乏真实可见的设计原则,由开发人员执行持续重构会导致代码难以理解或者难以变更。瀑布流会过度工程,过度工程可能会带来另一种担心:害怕做出深度,彻底的设计。

敏捷开发非常考验开发者的功底,而且敏捷开发由于一开始并没有对完整需求做出一定合理性设计,最后可能演变成一个大单体应用,错综复杂,痛不欲生。

主要优点

第一个版本会非常快出来,并且确保满足用户需求的情况下再进行下一步迭代,这种就像搭建一个2层楼小平房,中途可以按照用户要求各种改,非常低的试错成本,并且会搭建这种小平房的人相对比较多

沦落成大单体

业务初期,我们的功能大都非常简单,普通的CRUD就能满足,此时系统是清晰的。但是对着迭代的不断演化,业务逻辑变得原来越复杂,我们的系统也越来越冗杂。这里面很大一部分原因来自市场压力,竞争压力大,如果业务不快速迭代,就会面临淘汰,其实也没什么办法,确实活下来才是第一要务。我们的模块彼此关联,很难说清楚模块的功能意图是啥,往往修改一个功能时,要回溯的时间,以及回溯涉及的面远远超出预期。硬着头皮往前冲,最后全部业务逻辑耦合在一起沦为大单体。

对研发而言,很容易形成如下的恶性循环:

新入职的研发因为担心修改遗留代码而出现不可预知的BUG,所以宁愿增加大量不必要的代码,也不愿意去冒一点风险。会导致应用越来越大,功能越来越复杂,可读性越来越差,最终陷入恶性循环。

下面是常见的单体系统耦合情况

1)开发问题:所有的业务,开发人员都在一个大App上修改需求,代码提交冲突严重,RD哭了

2)部署问题:必须统一部署,统一上线,没有差异化而言,一周能进行2次没有问题的部署算是烧了高香,说好的高效呢,PM哭了

3)大表问题:所有的字段集中到一个DB存储,甚至就放在一张表中,DBA哭了

4)测试问题:没有边界,测试只能黑盒测试,需要回归大量的用例,QA哭了

领域驱动开发

毫无疑问,敏捷开发依然是现在项目初期非常好的一个选择,对于一个竞争非常激烈,生死存亡的创新型项目,完全可以用敏捷开发的模式。到达一定阶段后,会到瓶劲期(不过相信项目已经活下来了),那大单体的毛病就会凸显出来了。

技术层面的重构能解决吗

这个时候有的技术人员可能单纯从类内部,函数内部做优化,尝试找到一种合理性的局部架构。更有甚者,尝试将每个表封装成微服务的增删改查,然后嵌入到大单体应用中,这种做法现在流行叫做"分布式大单体",它除了改变请求协议之外,没有做出任何对业务有实质行的重构。

领域驱动开发认为:从技术层面无法看到全部问题,甚至只能看到很小的局部性问题。那么有没有一种解决方案能也从业务角度出发,涉及模型设计,代码开发全流程进行改造呢?有,目前普遍流行的DDD解决这个问题

DDD

前面描述到,DDD尝试从业务角度进行模型设计,所以以前产品和开发对话"对牛弹琴"的现象会极大减少,我们会在后面的篇幅介绍DDD如何解决这种普遍现象的。DDD包含的是一套从用户故事分析-领域划分-领域建模-领域实现的一套方法论。

DDD最核心的思想是使用建模来降低业务的复杂度。 

附件

看看单体应用的代码可以有多恐怖,和笔者的曾经的公司简直一摸一样。(截图来自B站,应该不会暴露公司隐私吧)

一个文件3000行,一个函数2000行,仅此而已。

 

 

Pre: DDD系列-聊聊敏捷开发模式的缺点

Next: GO语言设计模式 - 构建者模式

31
Sign in to leave a comment.
No Leanote account? Sign up now.
0 comments
Table of content