对某某软件架构认识与建议(非原创)
一、 某某架构
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两张图进行比较，你会发现，程序员不需要知道跟它无关的事情，而且统一了代码风格，如表现层不会出现key和PKValue两种不统一的字段，也不会出现按钮样式或按钮在各模块放的位置不统一；做完订单流程，同时也知道到了发货流程该怎么走，它们的关联一清二楚，之间有什么关系，做这一层的人肯定非常清楚。而横横向之间的衔接，就是SOA思想下的请求与响应。你请求，我响应，这不会给程序之间带来沟通问题。其实如果有设计文档，这些提前已经设计好。
以上是从开发模式上认识某某软件架构。
二、 架构改进
有了认识必然有一堆想法与建议，以下我用图的形式加以简略说明,这样比较直观。
1．数据层架构图
图10 数据层架构
好的数据层一旦建立，随着业务的扩充，一般不做修改，只需要稍微维护即可，在某某架构中，数据层是非常薄弱的，而且被分到OKComm中，这是不独立的，上面的数据层架构比较复杂，但从图可以看出它的最大好处是：跟业务无任何关系，只要是用到数据库的软件都可以用到此数据层，而且数据库是无限制扩展的，因为它是以SOA(面向服务架构)模式搭建，只需要扩展服务即可使用新的数据库，而且借鉴了开源NHibernate的ORM机制，让业务不出现任何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中做了说明。
三、 总结
记得大学里数据库老师说过一句话，可以拿到这里做总结。“做任何事，应该把它当做一项工程来做，才能做好。软件工程是一项工程，只有这样认识它，才能做好软件。”，无论是在某某架构中，还是在某某软件开发流程中，最后总结的建议就是：软件必须重视设计，才像软件工程，才能持久做好。
