软件开发的核心难度在于处理隐藏在业务知识中的复杂度。
自从进入了“敏捷”时代,大家都好像要以速度取胜,唯恐天下武功唯快不能破,业务部门的同学想着要快速解决业务问题,研发部的同学想着快速解决技术问题,在MVP的这个”舞台上“,总是你方唱罢我登场。
可是,一时快,真的会一直快吗。
大多数的情况下,追求了当时的快,美一点的说法,叫做“小步快跑”,但是,这个小步快跑,一定是要建立在业务问题定义清楚的情况下。
不然。
时间长之,产品演化,当初忽略或者无视业务定义的“一小步”,就会导致在产品演化道路上,走偏“一大步”。
那,我就要建模。
模型是对问题/业务的复杂度进行简化和精炼最好方式,没有之一。
建模的方法有很多种,现在想想,我当年初入编程世界,直接建库、建表,然后再写数据库表之上的业务逻辑,也可以称之为建模,为什么不是呢。它还有个漂亮的名字,叫做“着眼于数据库设计的实体关系建模法”=(E-R Modeling)。
后来,接触了OO思想,开始进行了OOA(Object Oriented Analysis)、OOD(Object Oriented Design),也就是我们常说的面向对象分析,面向对象设计,也可以称之为建模,为什么不是呢。
到了最近,DDD(Domain Driven Design),领域驱动设计更是一种建模的方法。
模型是抽象的,它没有实体可言,因此只能被用来表达。程序员用代码和文档表达,比如接口就是业务的体现。而业务人员呢,可以通过统一语言来表达。
注意,这里的业务人员,也可以是理解业务的程序员。比如,23种设计模式,SOLID原则等,某个角度来讲就是一种通用语言。
当然,你可能会说,如果业务方有一定的技术背景,与此同时呢,模型的修改又相对简单,那么也许可以跳过统一语言这个”步骤“,确切的说,这是可以的。
但是。
大多数情况下不能这么做,因为有一定的风险。
如果业务人员直接对模型进行了操作,就有可能将没有达成共识的内容或者叫做知识,添加到模型中,从而导致根据模式进行的技术实现,可能会变成另外一套东西。所以,还是需要依靠统一语言来解决共识的问题。
领域驱动设计针对的是复杂且多变的业务系统,业务人员和技术人员可以通过统一语言,建立好业务模型,驱动技术方案的设计和执行的落地。
针对隐藏在业务中的软件开发的核心复杂度的处理方法,领域驱动设计是目前较为可行的处理方式之一。
----END----
这里记录,我每周碰到的,或想到的,引起触动,或感动的,事物的思考及笔记。不见得都对,但开始思考记录总是好的。
与爱学习、爱思考、爱记录的你共勉。
祝大家春节快乐!祝奋战在一线的春晚项目组的同事们春节快乐!