一周技术思考笔记(第50期)-软件开发的核心难度在哪里

软件开发的核心难度在于处理隐藏在业务知识中的复杂度。

自从进入了“敏捷”时代，大家都好像要以速度取胜，唯恐天下武功唯快不能破，业务部门的同学想着要快速解决业务问题，研发部的同学想着快速解决技术问题，在MVP的这个”舞台上“，总是你方唱罢我登场。

可是，一时快，真的会一直快吗。

大多数的情况下，追求了当时的快，美一点的说法，叫做“小步快跑”，但是，这个小步快跑，一定是要建立在业务问题定义清楚的情况下。

不然。

时间长之，产品演化，当初忽略或者无视业务定义的“一小步”，就会导致在产品演化道路上，走偏“一大步”。

那，我就要建模。

模型是对问题/业务的复杂度进行简化和精炼最好方式，没有之一。

建模的方法有很多种，现在想想，我当年初入编程世界，直接建库、建表，然后再写数据库表之上的业务逻辑，也可以称之为建模，为什么不是呢。它还有个漂亮的名字，叫做“着眼于数据库设计的实体关系建模法”=（E-R Modeling）。

后来，接触了OO思想，开始进行了OOA（Object Oriented Analysis）、OOD（Object Oriented Design），也就是我们常说的面向对象分析，面向对象设计，也可以称之为建模，为什么不是呢。

到了最近，DDD（Domain Driven Design），领域驱动设计更是一种建模的方法。

模型是抽象的，它没有实体可言，因此只能被用来表达。程序员用代码和文档表达，比如接口就是业务的体现。而业务人员呢，可以通过统一语言来表达。

注意，这里的业务人员，也可以是理解业务的程序员。比如，23种设计模式，SOLID原则等，某个角度来讲就是一种通用语言。

当然，你可能会说，如果业务方有一定的技术背景，与此同时呢，模型的修改又相对简单，那么也许可以跳过统一语言这个”步骤“，确切的说，这是可以的。

但是。

大多数情况下不能这么做，因为有一定的风险。

如果业务人员直接对模型进行了操作，就有可能将没有达成共识的内容或者叫做知识，添加到模型中，从而导致根据模式进行的技术实现，可能会变成另外一套东西。所以，还是需要依靠统一语言来解决共识的问题。

领域驱动设计针对的是复杂且多变的业务系统，业务人员和技术人员可以通过统一语言，建立好业务模型，驱动技术方案的设计和执行的落地。

针对隐藏在业务中的软件开发的核心复杂度的处理方法，领域驱动设计是目前较为可行的处理方式之一。

----END----

这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。

与爱学习、爱思考、爱记录的你共勉。

 祝大家春节快乐！祝奋战在一线的春晚项目组的同事们春节快乐！