1、引言

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

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

3、二维软件划分

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

4、三维软件划分

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

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

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

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

5、四维软件划分

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

竟然没回复，失败啊。

不错，实际上是立体的，只是在实际应用时，一般只有产品的架构师能看到这个立体的东西，其他开发人员都只能看到平面的，甚至是线性的。

3维有点点晕，有什么作用？

没什么用，这个东西一般在架构师自己心里，不画出来

团队和项目大的时候有用。
但看一个软件，很难说明哪些功能属于哪些层面。
以上说的是一个软件的切割方法，可以用于团队的组织，任务的划分...

我懒得再说啥构架和框架的问题了，就楼主的问题说点自己的看法吧。
首先构架有几种风格，但是按照楼主这样分，我是第一次看到。
第二，我也不是说这样分不好，而是说有些问题在这里表现的不清晰。
1、我看不出一维和二维的程序机构上有啥区别，都是基于业务导向模块分割的。只不过再把每一个模块再分成层，但是核心的概念没有啥区别。
2、引入一个所谓的第三维，其实意义依旧不大。所谓的避免重复，但是如果不去思考为啥会重复，仅仅是去寻找重复意义不大。并且寻找重复是要基于一定实际操作的积累，不能做到在设计阶段就考虑到问题。并且即使是重复，如不能分析出重复背后的原因，那么就很难在业务层面判断其重要性。就如楼主所言，单纯的技术路线下划分。
3、一如以前，引入一个第四维，其实还是换汤不换药。引入时间概念，我是搞不清楚究竟要解决啥问题。所谓的对版本有概念，但是依然存在技术路线单腿走路的老问题。节奏感来自哪里，应该按照什么做指引得到节奏都还是问题。而且版本是个啥概念呢？每一个版本究竟应该按照啥标准解决啥问题？这些都没有说。而且即使说了，又能咋样。程序的结构就会按照时间轴发送变化了？归根结底还是没有解决技术路线的问题。

说简单点，这样的划分在团队和项目大的时候会造成忽悠，而且越大越容易忽悠。
而且一个软件如果不能说明哪些功能属于什么层面，这样的框架和构架又有啥用，忽悠罢了。
说明确写，这个方法就是用一个方法来做切割，而且过多的考虑了团队的组织和任务的划分，已经技术，而业务本身和程序的合理业务表达对应能力根本就没有考虑在内。这样的东西说了和没说意义差不多，都属于炒作概念的政绩工程。

这个分法确实是个人愚见，属于原创。
  至于忽悠，犯不着，因为这些是将实际走过的道路进行了一些理论上的梳理。
  第二维引入的D轴实际上是随着软件开发的复杂而引入，为了将划分方法完整化，适应现在大多数N层架构而已。
  第三维的引入，这在我见到的绝大多少上了一定规模的公司(华为，西门子，UT...)都存在。对于较长周期的产品和较广的产品线的研发部门，需要这种切分的思路，而后一般也会成立相应的组织来实现，譬如架构组负责技术平台的建立，各产品线的平台组负责业务平台的搭建，各个项目和产品负责具体业务的实施。
  时间概念的引入，看似无关紧要，但是心中没有一个长远的规划，摸着石头过河的软件开发，最容易失去节奏感。

继续忽悠。
复杂性带来的分解应对策略，是一种最普遍的处理问题的策略。这一点完全没有问题。但是多层结构的产生的初衷在于各种资源进行包装，以使其各自具有相对独立性，从而可以封装变化。而这种方式的一个最普遍特征就是打破以需求为导向的纵的划分，而使用横的形式来划分。即便如同你所习惯的从人员分配的情况看，也是更加从横的方向来做，而很少考虑所谓的需求的模块。而把这两种本来是比较对立的方式强行添加到一个模型里面统一表示，自然是一种忽悠。
第三种方式存在与否并不是重要的问题，因此其是否存在并没有一个验证的标准，你可以说存在，我可以说不存在，而其实关键还是在于我上次回答中所认为的，核心还是找到原因，针对原因去采取措施，而不仅仅是针对现象。不可否认的事实是，产品线、构架、框架已经成为一系列常见的企业集团化构建系列应用的常见形式。但是这些情况的产生并非是为了针对避免重复，而是企业采取主动措施促进复用。这里的区别是很明确的，所谓的避免重复，完全是为了消除重复，而针对性的将重复的部分加以集中。而复用的方式则在于，产生通用性强的组件，并将这些组件进行组合去尝试着生产新的价值。可以说这两者就动机一个是被动，一个是主动。而就形式来说，前一种是在实际中去提炼；而后一种则是以一种原则为出发，在实际中去实体化。就业务意义来说，前者是业务无关，而单纯技术导向的，而后者是业务和技术双重约束的。而这两种方法，貌似可以平滑过渡，但是在实际操作中根本就无法取得平衡。就如同楼主说的，在华为、西门子、UT等组织都是使用这样的方式，但是请大家注意这些企业都是大型企业。让大型企业从一种生产方式，平滑过渡到另外一种，这是不可能实现的管理诉求。而且从底向上和从顶向下的这两种方式，不仅仅造成的影响是生产方式的不同，还会造成管理策略，市场层面，销售手段，以至于公司战略层面的巨大不同。因此不加深入分析的，凭浅层的表象看，当然是前一种形式，必然会导致后一种形式。但是这仅仅是表象所显现的情况，而把表现的结果当实际的问题，就是一种忽悠。
第四种，所谓时间的概念，我实在无法理解楼主到底要说什么问题。时间照顾概念很重要，并且从软件开发存在的那一天起就很重要。自然时间约束的不同带来的设计和实现方式会不同，傻瓜才会把一个3个月的项目同一个3年的项目采取同样的设计和构造策略。但是这里并不存在所谓节奏问题，而仅仅是规模的问题。同时我们也要注意，所谓的企业长久计划已经是一种管理学上的玩笑，现代企业更加注重的是反应和应变能力。实际上由于环境的快速改变，竞争的存在，市场的动态性，采取计划推动的方式最容易没有节奏。这种情况下，摸着石头过河，才是最佳的掌握节奏的策略。而同时由于大型企业普遍采取的基于产品线的核心资产构建产品的形式，使其产品的开发和生产更加具有灵活性而低成本性。这一段同楼主所说的完全是南辕北辙。

真是不好意思，在另外一个贴里面(闲聊软件过程)，在请教o...z，在这里缺需要提不同意见:
1.我认为楼主的划分还是有一定的道理的，书本来就是薄到厚，又从厚到薄的过程。你是因为过了这个阶段，才认为其是忽悠。我认为是不错的总结。
2.第二维的引入，试图去解决软件实现优化的问题，即更好的实现某个功能。
3.第三维的引入，已经上升到了注重积累、强调复用的阶段。
4.第四维的引入，我觉得你好像没有理解楼主的意思(也许是我没有理解你，你的文字说实在还是比较难以读懂的)，我认为他说的是技术方面持续改进的规划，对于产品中的核心模块、组件等来说，我觉得这是非常重要的。

上面是我对楼主四维论的理解，话又说回来，当这些都成为常识后(并不是人人都具有的)，基本也没有多大的价值，就向对o..z。