软件产品的四维立体分解法

1、引言

  最近为公司做一些架构方面的整理工作，记得以前给新人写过一篇PPT，关于软件的认识方法，其中对软件的划分方法值得借鉴，于是整理出本文。

2、一维软件划分

  回想我刚开始做软件开发的时候，对软件的认识，停留简单的表面，收到客户的需求，分解成为几个模块，划分几个人手，吭哧吭哧上马干活，这个时候的对软件的认识，犹如小孩子对几何的认识，仅知道几个点连成一个线而已，姑且将这种认识层次，或者说采用这样的观点划分的软件，称之为：

3、二维软件划分

  刚开始的时候，做了一些桌面型的应用Delphi(C++Builder)+Interbase，VB+Access，这种单纯而直接的应用开发岁月没持续多久，还没等我用上传说中最牛叉的Power Builder，CS，BS，三层，N层架构就接踵而至，作为可怜的开发人员，学完这个学那个，真实的需求根本没有，完全是技术驱动的学习。
  在多层架构下，软件产品和开发角色的划分，也跟着进行了细分，大家往往将服务器、客户端开发人员分开，大的项目，甚至有单独DBA，此时的软件划分，已经不再是一维的，而是二维的：

4、三维软件划分

  二维的软件划分，可以用于大多数项目的开发，对于小公司特别有效，但对于一些大的项目或者产品的开发，总显得那么捉襟见肘。
  这是因为在大的团队，随着产品开发的时间累计，不断有避免重复（现在流行的叫做DRY），加强建设产品公用部分，节省人力的需求，这时候，往往会成立单独的平台组，系统组，将团队的核心知识固化在一些可复用的软件模块中，将这些软件模块包装成为平台，框架，构件等。
  在这个时候，对软件的认识和划分，需要摆脱二维软件单纯的平面思想，进行三维立体的划分：

  三维软件的划分方法，相比于二维，主要增加了一个逻辑轴，该轴的一般体现了软件的平台，框架，构件等思想；我个人一般将该维的层次划分为

1. 外部Library
2. 技术平台与框架
3. 业务平台与框架
4. 业务实现

  相信不同的公司，不同的人对这块的划分都有不同的认识，但是，引入了第三维，软件变成一个立体的，可触摸的东西。

5、四维软件划分

  三维的软件划分，是一个单纯的技术路线的划分，考虑到软件开发的实际情况，总觉得缺少点什么，对了！时间，就是时间。
  时间在软件的开发中，毫无疑问是非常重要的，静态的看一个软件是不现实的，我们站在时间轴上去看软件，软件才是一个有生命力的，活生生的。
  开发一个软件产品的时候，即便我们能够按照三维的思路将目标产品进行分解，或者对现有产品划分，但如果没有考虑到版本因素，这样的产品开发无疑是不具有可行性。
  好的架构师，需要对产品的版本特征规划胸有成竹，对于产品的开发具有很好的节奏感，这就构成了软件的第四维。