一种新型的系统设计解决方案：模块树驱动设计 _系统设计

一、前言
系统设计的核心作用是在业务现实世界和抽象的IT实现之间建立起一道桥梁。

与其他行业被物理特性限制所束缚不同，软件世界可以变得无限庞大，而限制软件发展的其实是人的认知能力。所有软件设计服务的目标其实都是管理人的认知，是关于人有限的精力如何学习软件中无限多的知识（Knowledge）的问题。

软件行业从传统的瀑布开发模式，过渡到了敏捷开发模式，对于文档，敏捷宣言中说的是“工作的软件高于详尽的文档”，但实际工作中开发人员写的文档是越来越少，或者是能不写就不写；流程上，更是恨不得需求还没有出来就直接撸代码，撸完代码就直接上线。

缺乏整体系统设计，设计出来的系统就不够完善，再加上快速的系统迭代，导致系统越来越难以维护，开发成本越来越高，一个项目需要参与的人越来越多，最终没有人能够说明清楚，这个系统具体是如何运行的了。随着团队人员的更替，加上每个人的设计思路又不一样，更加加重了系统的复杂性。
上面也就引入了两个问题：

缺乏文档问题：不清楚系统长什么样？
软件复杂度高的问题：迭代修改系统的成本高。

上面两个问题在MTDD都有相应的解法，后面我们会详细讲述，接下来我还是再详谈一下软件复杂度。

2、软件复杂度
2.1 软件复杂度的症状和原因
《软件设计哲学》这本书中提到，软件复杂度的三种症状：

变化放大：需要修改一个地方，却发现改动的点涉及全站，导致难度倍增；
认知负荷：开发者需要完成一项任务的知识量；
未知：开发者在修改代码后，不知道它的实际影响面。

为了从源头上解决这些问题，John Ousterhout教授提出：从项目一开始就要严格遵循进行软件设计的原则，那些为了赶工期而没有经过良好设计的代码，最终经过多次迭代后，都会变得越来越臃肿，继而变得再也无法维护了。

我非常认可John Ousterhout的观点，但
实际操作中发现基本不具有可行性，原因：

.从瀑布模式到敏捷开发，已经很难回去了。
是否遵循良好的软件设计原则很难衡量。
没有这么多的时间来检查（代码review，设计renview）是否有按照这些原则来设计和编码。

我的观点

对于“简化模块依赖”，“减少模糊性”，“高内聚低耦合”这些原则的话术，知道的人就知道怎么做，不知道的人还是不知道怎么做。这些术语缺少实际的指导性。

2.2 软件复杂度是怎么引入的（另外一个角度）
2.2.1 我们来看一个例子

文章插图
图片

2.2.2 系统到底是谁做出来的
一个有意思的现象：

文章插图
图片

【一种新型的系统设计解决方案：模块树驱动设计】
那系统到底是谁做出来的呢？（这里主要说的是业务系统。一些中间件之类的系统，基本都都由研发来完成的。）

文章插图
图片

系统设计离不开，业务人员、产品经理以及技术研发的合作，业务和产品的需求没有理清楚，同样会导致系统复杂度提升。

2.2.3 另外一种系统复杂度引入环节

文章插图
图片
系统各主要相关方缺乏对系统设计的信息拉齐，给系统复杂度的提升同样有重要的贡献。
那么如何让各角色更好的进行信息对齐，这就引入了MTDD 。

3、一种新型的系统设计解决方案：MTDD前面提到了《软件设计哲学》作者提出了一些系统设计总结，也有些人提出了一些方法论，比如领域驱动设计（DDD），测试驱动开发（TDD），行为驱动开发（BDD）；但是这些模式，都是从设计方法论上给与指导，战术上指导偏少。下面我们来介绍我自己沉淀的一个方法论，和战术指导MTDD&MTDP 。