软件架构设计(一)



记得在北航上课的时候，听《web services》的课程时，老师拿出他们做的项目方案PPT给我们欣赏，里面就有很多的设计图纸，当时真是叹为观止，那些五颜六色的方块真规整，排列的那么有序，条理那么清晰，心里想，我什么时候可以做出这样的东西，我就牛了。后来进入公司，发现这样的东西很多，大多是那些做产品的人做出来的，主要供演示用。慢慢地随着自己在公司的地位不一样，发现他们做的和我们设计的完全不一码事（可能有点夸张，呵呵）。

 

架构设计似乎是一个无形的东西，但她又确实存在；她没有定式，但有门派之分，因人而异。平时在网上也搜一些架构设计类的文章看看，可发现大部分是理论的东西，能被实际利用的成分并不是很多，这里我只谈谈我自己的一些体会。顺便说一句，我并不是鄙视理论，相反我很崇尚理论，因为如果一个认知没有理论支持，那么你的认知可能是不清晰的甚至是错误的。俺没有理论功底，所有只能谈谈一些形而上学的所谓实践吧，有不同意见，请多赐教！

 

要描述一个软件产品架构，绝对不是一张图纸能解决问题的，我根据自己的经验，作了一个简单的步骤或归类，认为她应该由以下几个构成部分，即产品原理图、系统构成图、核心模块图、层次架构图、业务流程图、接口协议表、网络拓扑图。

 

1、产品原理图

  架构是因产品而存在，脱离产品而谈架构，那是纸上谈兵。产品设计的正确与否，是后续软件开发成功的基本保障。

  当一个新员工加入你这个团队的时候，他往往会提出有什么文档可以供他参考？在很多时候，所谓的领导往往是给一个大部头的产品设计说明书作为反馈。唉，可怜的新员工。我认为，如果有一个简单的产品原理图，再花上几分钟时间给讲解一下，新员工融入团队的时间将会大大缩短，而且心理也会有一个底，不会产生来了不知道自己做什么的感觉。

 

  我认为产品原理图必须具备以下几个特征：

  1）产品产生的背景

     产品一定是要解决某个问题或者实现某一个想法，她因问题而生。把问题描述清楚了，每个人心里都有自己的解决方案，后面大家就会畅所欲言，团队的力量就会显示出来。

  2）产品的定位与性质

     在我个人做的所有产品中，都不会有一个产品是完全独立的，总跟其他产品或平台有着千丝万缕的关系。描述清楚该产品与其他产品是一个什么关系极其重要，比如是旁路设备还是核心设备（因为这涉及到产品间是串行化设计还是并行化设计）。产品是定量分析还是定性分析，比如银行系统，那就对准确性和可靠性有近乎苛刻的要求，但如果是数据挖掘的统计性分析，则对个别的数据没那么高的要求。所以产品的性质十分重要，这对以后的核心系统的设计有决定性的影响。

  3）产品的设计原理与思路

     前面的问题有了，那么解决思路就一定会有的，因为方法总比问题多！产品设计的原理主要描述如何解决这个问题，以及使用哪些技术或公司已经具备的技术来达到解决目标，即我们最终是要解决一个什么问题（此问题非彼问题，呵呵）。此时的问题已经非常具体，程序员一看就知道自己要做什么了，剩下的问题就是如何分工协作了。

 

  当然，产品经理画出的方案图与我们程序员画出的原理图往往有较大的差异，毕竟各自的侧重点不同，所以我认为程序员自己画一个产品原理图那是相当有必要。下面就将我以前的一个项目的草图（请注意是草图哦）拿出来作一个对比，看是否能将我的观点形象化一下。

 

   这是产品经理的方案图

 

     

 

    这是我自己画的原理图