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

1、引言

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

2、一维软件划分

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

3、二维软件划分

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

4、三维软件划分

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

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

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

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

5、四维软件划分

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

评论

12 楼 ozzzzzz 2007-11-17  

kadvin 写道

鄙人第一次在JavaEye上面发帖，说实话，做软件也不少年了，但一直属于潜水者，但对于灌水这件事情还是比较生疏。

本文写的比较匆忙，在写的过程中，还遇到JavaEye把内容丢失的情况，后来好像是他们将这个内容恢复过来，而后没有再添补什么就直接选了一个论坛发表了。

其实关于这块东西，还有很多实例可以补充，但由于本人工作比较忙，没能写那么翔实。

非常感谢o...z同学着墨如此之多的回复在下的愚见，我同意你的观点，不过，这篇文章并不是一篇讲架构的方法论，而是讲软件的认识论（不过，认识也会指导行为的方向），尝试提供一个简单的方法，来剖析软件，我的本意是咱们拿出四把刀，遇到一个软件，看看能不能直接用这四把刀把它给切了，从第一维的刀开始切，一直到第四维，有些软件比较简单，不需要那么复杂，可能切到第二刀，第三刀就可以了。

PS:o...z兄的文字实在是多，我看完有点晕，觉得被你忽悠了才是:D

首先，我觉得还是一个认识方法问题。恰恰就在于你试图用一个线索了解释软件开发思路的变迁，而实际上这个事情应该是多线索的。
其次，你讲的应该是思路的发展历史。按照时间顺序就可以了，究竟是以什么为规律，还是交给听者自己体会。
最后，我们遇到一个软件究竟该如何分析，并且随着环境的变化以及系统的变化修正自己的分析方法，这不是一个简单的事情。而你试图用简单的方法分析复杂的问题，在大多数情况下都是会失败的。
我文字确实比较多，而且很多部分不是针对你的，分清楚就不晕了。这年头我已经学油了，骂人都是在说其他的事情的时候骂的，所以你也不要对号入座。不过我确实觉得你可以以前是埋头干活太多了，自己思考总结的时间太少了。

11 楼 kadvin 2007-11-17  

鄙人第一次在JavaEye上面发帖，说实话，做软件也不少年了，但一直属于潜水者，但对于灌水这件事情还是比较生疏。

本文写的比较匆忙，在写的过程中，还遇到JavaEye把内容丢失的情况，后来好像是他们将这个内容恢复过来，而后没有再添补什么就直接选了一个论坛发表了。

其实关于这块东西，还有很多实例可以补充，但由于本人工作比较忙，没能写那么翔实。

非常感谢o...z同学着墨如此之多的回复在下的愚见，我同意你的观点，不过，这篇文章并不是一篇讲架构的方法论，而是讲软件的认识论（不过，认识也会指导行为的方向），尝试提供一个简单的方法，来剖析软件，我的本意是咱们拿出四把刀，遇到一个软件，看看能不能直接用这四把刀把它给切了，从第一维的刀开始切，一直到第四维，有些软件比较简单，不需要那么复杂，可能切到第二刀，第三刀就可以了。

PS:o...z兄的文字实在是多，我看完有点晕，觉得被你忽悠了才是:D

10 楼 ozzzzzz 2007-11-16  

ideafrog 写道

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

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

我不觉得这个是理解深浅的问题，也不是理解的阶段性的问题。而是看问题的角度，和研究问题的方法的问题。实际上最近我在做一个FDD方法讲座的筹划的工作，在这其中我发现我的世界观和方法论都同以前有了很多的改变。而追究原因，并非是因为我对问题研究的更加深入，而仅仅是我能够更多的从自己是的实际经验出发去思考问题，而更少的受书本和他人学说的约束。

实际上我是经过分层理论的热烈传播起的，里面的来龙去脉还是比较清楚的。这里其实是一个历史观的问题。其实我们都应该清楚，历史上很多事情现在看起来充满来偶然和必然的结合，并且事后分析相关人貌似神秘的存在着深谋远虑的可能。而实际的情况是，当时的当事人仅仅是按照当时的情况被逼无奈，选择了一条当时看来最可行的路。这样逐步发展，造成了一个他神秘的深谋远虑的印象。但这仅仅是一个印象，这整个印象说成是实际发生的现实，那就是一种忽悠。

而更加关键的是第三维多引入存在诸多的问题，特别是如果和你所认为的第四维结合就更加说不通。这里我抛开企业级的复用和总结积累的关系不大的问题不谈（其实以前企业复用失败的根本原因就在此，也就是大家都误以为总结和积累才是复用的基础），就假设其复用的核心模块和组件是来自总结和积累。而实际上大家都会有体验，总结和积累存在一个量变到质变的问题，这一点是不以你意志为转移的。也就是说你无法计划好，你的总结和提炼在什么时候才能发生质变，从而去带动所谓的节奏化。而显然如果是你的持续化改进来自总结和积累，实际上如果保持测试的完整和构建技术的协调，你的改进就可以做到均匀进行，而不需要考虑节奏。另外还必须考虑到，既然来自总结和积累，外部环境的改变就会成为一个非常重要的要素。而外部环境的改变，我如何要看不出可规划性（除非他自己高呼：我就是上帝），这个时候又如何谈什么节奏性呢？

其实说实际的，楼主想要做的就是想找到一条线索把程序设计思想的发展趋势从前到后连续的构成一个链条。可惜的是，世界的发展是非线性的。这个是世界观的根本问题，而不是认识的深度问题。只要不建立起这个思维方式，你研究的再久再深入，依然没有啥大的进步。

9 楼 ideafrog 2007-11-16  

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

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

8 楼 ozzzzzz 2007-11-16  

kadvin 写道

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

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

7 楼 kadvin 2007-11-16  

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

6 楼 ozzzzzz 2007-11-16  

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

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

5 楼 kadvin 2007-11-16  

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

4 楼 诺铁 2007-11-15  

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

3 楼 抛出异常的爱 2007-11-15  

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

2 楼 诺铁 2007-11-15  

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

1 楼 kadvin 2007-11-15  

竟然没回复，失败啊。