架构人生

对某某软件架构认识与建议

一、    某某架构

1.从“层”上认识某某软件架构

软件业中Web最经典的架构必然是三层架构:表现层,业务层,数据层。那么让我们看看某某软件在三层架构上是如何实现的(如图1):

项目

认识

表现层

Zivsoft.CRM

Zivsoft.CRM.Controller

表现层应该只对界面的表现形式做控制

业务层

Zivsoft.Business

Zivsoft.Ajax

Zivsoft.Email

Zivsoft.Resource

Zivsoft.Report

业务层应该只跟具体需求有关系,是商业软件的真正核心。

数据层

Zivsoft.Comm

数据层必须是独立,是必须可扩展的一层。

                      图1某某软件项目以三层划分

从上面的表格中,可以看出,有三层的影子,但再具体看项目,发现三层分得不太明确,但又像MVC分层(如图2)

项目

认识

Model

Zivsoft.Business

Zivsoft.Report

Zivsoft.Ajax

代表系统的模型层

View

Zivsoft.CRM

模型的展现层

Controller

Zivsoft.Controller

负责业务的流转

                       图2某某软件以MVC层划分

总体上,感觉某某软件比较像MVC架构,这是我的认识。总体感觉有架构的影子,但是似乎又没尽力做到最好。

 

2.从“开发模式”上认识某某软件架构

首先,我们从软件流程上来分析:

假设我们现在从客户得到了一个新的需求,那么,会有很专业的人员理解需求,并将需求带回公司。某某在这一环节做得很好,如图3

 


                                                                                              图3 客户需求提出

 

但是,需求分析后的下一步,需求人员开始与程序员沟通,于是开始编码, 即使程序员在编码前花了一些时间做了设计工作,甚至还拿到了文档(注:此文档一般都是需求文档,而非设计文档),具体流程如图4

 
4 需求到编码的跨越

于是,接下来,就开始走一下流程(如图5)


5 最耗时间的死循环

 

 

那么现在让我们继续看下面的流程,如图6

 

6 软件实施

现在对以上流程谈一下看法:

在需求提出上,我个人认为做得很好,当客户想要新的功能,无法用软件表现时,需求人员提出自己的解决方案,让客户满意,并将需求与解决方案带回公司。回公司,只要沟通没问题,其实需求文档并不重要,但一般软件开发还是要写需求文档,因为需求文档毕竟是文档,它可以便于以后复查,这是它的主要好处。

但是,我总认为,软件是一项工程,某某的流程走得似乎过于简单,编码前的设计与分析,以及扩展性,还有可行性,另外现有的框架是否满足这个新需求的到来,等等,这些似乎没过多考虑,而直接开始了编码工作。

先看看软件设计要做的事如图7

阶段

事务描述

概要设计文档

对需求人员提出的需求变成开发文档,并分析是否可行,可行继续写详细设计文档,不可行和需求人员沟通对需求做出调整,以适应开发,继续做概要设计分析;另外有可能需要调整系统架构等等,然后来适应开发和软件的后续稳定性和扩展性。

详细设计文档

接口设计

设计者此时必须以开发人员的角色去分析需求。并设计好接口,数据库结构,各表关联,以及界面表现形式。还有可能需要对架构等等加以调整和扩充,从而满足新需求不会影响到已经存在的模块。

数据库设计

界面设计

备注:

以上是我个人认为很重要的环节,因为很多的Bug都是因为事先考虑不周,或者设计不合理导致的,以及扩展性难,当然作为框架设计不合理,也会导致新需求的加入造成不稳定性,而这一切如此重要,却被某某忽略,于是总有“不稳性”的阴影,从而大家都在改永远改不完的Bug。因为没有事先的设计,从而让我们陷于如图5的死循环中,再回头已不能自拔(如Zivsoft.Comm,DataGrid一动全惊动,杀掉一个bug,而另一个新bug却悄悄诞生)。

 7 软件设计的重要环节被忽略

作为流程后面的发布与测试,我认为没有多大问题,还是佩服某某花了大力气,大人力来做这件事。只是感觉祸源不在此。

 

其次,也就是最后要分析的是研发内部的开发模式:

同样,从新需求开始分析。

当一个程序员接到新需求,由于软件架构分了层,那么分层的另一个好处却没有利用起来(本可以利用),我们先看图8

 


8 纵向开发

分层的好处不仅可以把业务独立,让数据库容易扩展,同时界面可以随意适应客户需求的改变,这是它的主要好处之一;另外,分层在开发上,它可以让不同特长的程序员发挥它的专长。如对需求把握比较好的人,它可以去做表现层的开发,这样界面就比较统一,而且对需求的实现也比较精确;若对需求把握不准,可以去业务层开发,因为它只需要实现被设计好的接口,另外所有的业务之间的关联,如采购,订单,发货,将会非常清晰;至于底层的开发,一般需要性能分析,以及架构的知识,但这一块变化不大,架构,设计者可以开发这一块。现将上面的纵向开发模式改成横向开发模式,如下图9

 


9 横向开发

将图8,图9两张图进行比较,你会发现,程序员不需要知道跟它无关的事情,而且统一了代码风格,如表现层不会出现keyPKValue两种不统一的字段,也不会出现按钮样式或按钮在各模块放的位置不统一;做完订单流程,同时也知道到了发货流程该怎么走,它们的关联一清二楚,之间有什么关系,做这一层的人肯定非常清楚。而横横向之间的衔接,就是SOA思想下的请求与响应。你请求,我响应,这不会给程序之间带来沟通问题。其实如果有设计文档,这些提前已经设计好。

以上是从开发模式上认识某某软件架构。

 

二、    架构改进

有了认识必然有一堆想法与建议,以下我用图的形式加以简略说明,这样比较直观。

1.数据层架构图

 


10 数据层架构

好的数据层一旦建立,随着业务的扩充,一般不做修改,只需要稍微维护即可,在某某架构中,数据层是非常薄弱的,而且被分到OKComm中,这是不独立的,上面的数据层架构比较复杂,但从图可以看出它的最大好处是:跟业务无任何关系,只要是用到数据库的软件都可以用到此数据层,而且数据库是无限制扩展的,因为它是以SOA(面向服务架构)模式搭建,只需要扩展服务即可使用新的数据库,而且借鉴了开源NHibernateORM机制,让业务不出现任何Sql语句,同时与物理表脱离,从而达到数据库一旦修改而不影响业务代码的修改。

下面是数据库的扩展方式,如图11

 


11 如何扩展数据库

2.业务层架构图

 


12 业务层架构

业务层架构相对数据层架构,稍微简单一些,但是随着需求的变化,业务的扩充,业务的比重将是整个架构的核心,从而成为软件企业重复利用的商业业务库。它好比一个工厂在铸造零件,当零件渐渐积累多了,用它们来生产产品将越来越轻松,软件企业亦是如此。

其实某某架构在业务上做得很不错,只是有一些遗憾,因为它像三层架构,但更像MVC,所以Controller对于某某架构比重占得比较大,如果是MVC架构,那么可以说得过去,但如果它采用的是MVC架构,那么我看到了OKBusiness这样一个项目,所以又不全是MVC架构。

以上架构图是对某某架构的改进。它增加了业务索引,因为我觉得业务代码像是一个工厂的零件库,而业务索引就像书签,便于查找的作用。同时去掉了Zivosft.Comm这个四不像的项目,因为它似乎什么都是,但却什么都不是,于是我个人文为应该将它部分功能封装在IO层的API中,因为它毕竟是表现层与业务层衔接的枢纽。

 

3.表现层架构图

 


13 表现层架构图

如图13,由于SOA架构是面向服务的架构,所以业务层是表现层的服务,那么这就让表现层是最简单的一层,因为它只做界面控制,只需请求业务而已。而实际上某某架构中,刚才业务架构中提到,它的比重却占得比较大,而且是把Zivsoft.CRM与Zivsoft.Controller分开,改起来不方便。在这一层中将Plug-in引入,是因为很多东西可以独立出来,或者应用第三方的组件,某某架构中的DataGrid是一个最典型的见证。而中间件的定义和要求在图13中做了说明。

 

三、    总结

记得大学里数据库老师说过一句话,可以拿到这里做总结。“做任何事,应该把它当做一项工程来做,才能做好。软件工程是一项工程,只有这样认识它,才能做好软件。”,无论是在某某架构中,还是在某某软件开发流程中,最后总结的建议就是:软件必须重视设计,才像软件工程,才能持久做好。

 


本文链接:http://www.cnblogs.com/architect/archive/2009/03/18/1414994.html
作者相关:http://www.zivsoft.com

posted on 2009-03-18 00:01 周利华 阅读(...) 评论(...) 编辑 收藏

导航

公告