商业应用架构

一. 谈架构，先从什么是架构谈起.

架构一词，本用于形容如何通过某些工具而达到某种目的的实现，并不需单限制在IT领域.

在IT，架构普遍指通过某种特定的平台，而达到完成整体软件的功能.

而所谓的特定的平台，更被结构化地分为了多个层.

先举例说一个最最平常的4层应用程序。分为
1 表现层 UI
2 功能层 ACTIVITY
3 数据处理整合层 DATA MANIPULATION
4 数据持续层 DATA STORAGE

所以说以上的四层经典,因为它很好地符合了广大商业模式和商业软件的需求.其中包括.
1 用户界面 ( 有C/S 和 B/S 之分 )
2 可以频繁改动的,有时候非常怪异的客户端行为,另外如权限安全也可以放在这里.
3 为了使 2 得到透明的数据库, 必须使用 3
4 只作为程序的容量,规模,以及安全性的考虑,使用不同的数据库甚至文件系统.

二. 为什么要谈架构.

1 架构决定了软件的功能.决定了软件的能力.如公司的各个部门在不同的防火墙后面,各个部门在不同的地区,各个地区又没有专门的MIS部门对计算机提供支持,这些情况就会导致B/S结构比C/S要方便很多.

2 用户的行为很怪异,有的部门主管在签名文件的时候不需要得到上级的认可,有的却需要和多个部门以及上级交流并保存签名的文件的多个copy到别的部门.这个时候 功能层 就负责这些无聊又繁琐的逻辑.并且请注意,这些逻辑会不断改变.

3 在我们开发的角度来说,总是希望写些不用频繁改变的代码,而且有的程序员同志又不希望理睬无聊的客户要求,他们就说"得,我做些你们都喜欢我做的工作", 因此 数据处理整合层 就产生了.

4 最不由我决定的一个层就是 数据持续层.比如我公司就有免费的(因为是我们的集团购买了)oracle,有时候他们就不想再用10多万来用用sql.我们做程序的最多时给对方一个建议和选择,比如告诉他们"oracle的维护费用很贵,我们也不大精通阿同志"

三. 谈了架构又真的有用么?

我们这里先看看一个程序要开发出来的必要充分条件是什么
首先,要有需求
其次,要有资源

需求,由市场决定,没有任何定式,大而繁杂
资源,包括人力,时间两个重要的要素 (顺便一提,这个就是it同志经常加班的该死的原因)

我举几个例子说说很难真正地谈架构.

1. 我们在谈 "二. 为什么要谈架构." 的时候,我说了很多关于用户相关的东西,如各个部门经理有不同的需求,和各个登陆人员的权限不同.
大家刚才给我骗了,我告诉你们说在 "2 功能层 ACTIVITY 功能层 就负责这些无聊又繁琐的逻辑". 其实不然.客观来说,几乎所有的层都和权限以及用户逻辑有关系.
打比方说,不同权限的人,登陆同一个页面,就应该开到不同的功能按钮.如部门经理,在看到员工信息的时候,就应该有删除员工这样一个按钮,但是员工就不能看到.
那这个要在 "1 表现层 UI" 实现的功能为什么我们在 "2 功能层 ACTIVITY" 还要再做一次?

2. 在上面我说 "为了使 2 得到透明的数据库, 必须使用 3 ", 我又骗了人了,没有一个数据库能真正的做到透明, 举个例子说,在
"2 层" 的程序员B,要是不知道数据库的结构,他怎么和 "3 层" 程序员C写的接口交流, B不知道数据库结构,他怎么和C交流?
那么在我看来这个状况就很怪异:

首先,在开发资源来说,既然B同学要做的工作,A也要了解一部份,那我为什么不安排A和B在一个做同一个层,而要他们做自己各自的工作.或者这样,你们在B的位置想一下,B要是不理A的需求,自己弄自己的接口,那可能他做了100个接口,其中只有50个是A需要的,另外25个市A不满意的(比如说对返回错误信息的不满意),还有25个是完全没用的.我为什么要浪费B的能力做那25个无用的接口?

其次,在需求发生改变的时候,分的层越多,改动的量就越可能大.很多同志会说"这个怎么可能呢?分层就是为了最小的改动".所以我说"可能大"而不是"必然大",为什么这么说呢?
如果是界面的改动,那也许很小,或者是用户行为的变化,这个改动也许也不大.
但你没有在一个项目经理的角度考虑问题,当一个改动发生的时候,就必须在软件的各个层上进行细致的考虑.
如:我们把 1, 2, 3, 4 层的程序员分为 A, B, C, D
当A改了他要改的东西,B是否要改相应的函数?B是否要提供另一个不同的TRANSACTION?C好像任何改变都与他无关但当B对他说"我需要一个新的api"的时候,C就要跳楼了因为C发现D的数据库根本没有这样的column.这个时候你们还会认为A不用知道D在做什么么?

3. 速度问题
再来看看我们最最底层的D同学,他是负责数据库的.有一天我的客户向我投诉程序越来越慢了.
我问了A,A说是B的反应太慢了,B又说C就这么慢,我就去把C给叫来,C告诉我说他不干了,他说"你要求怎么这么多,我又不是单对B工作,我还要处理B1,B2,B3等,他们要的column都不大一样,我就把表的所有column都要过来了".我没了主意就去找D商量,看他能不能让我们可爱的数据库跑快点.D说一个表就有1000万条记录,C一个Select就left outer join 了6个表,他问我"给你做index, 你怎么做?",我说"对您不住,都是我的错,我也不知道怎么做".

结论:

1 我不时说架构这个东西不好,而是说要有一个平衡,不要为了架构而架构.有些很复杂的要求其实用很简单的方法就可以解决。
2 即使架构好,你的客户才是上帝,我陪客户喝酒大家高兴弄到我第二天不能上班好过我加班改1个星期的代码.你要是真的要写一个能满足无限个单位无限个需求的大型商业软件，那也许功能和二次开发比架构更加重要。
3 老式的垃圾的传统的落后的瀑布开发和混乱开发模式,以及2层,或者假3层的应用程序,有时候更能满足大家的需求.
4 很多英雄老是讨论J2EE和.NET对商业应用的支持,但是真用起来,你又能做多少选择?用哪个,也不是你决定的.是让市场决定的.你是很无奈的,不是么?

我也是.

引用一句话“你不能做到你想做到的任何事情（功能），当你能满足你（客户）希望的70%时，就很难得了”

<!-- google_ad_client = "pub-3051157228350391"; google_alternate_color = "FF0000"; google_ad_width = 300; google_ad_height = 250; google_ad_format = "300x250_as"; google_ad_channel ="2408491454"; google_ad_type = "text_image"; google_page_url = document.location; google_color_border = "FF4500"; google_color_bg = "FFEBCD"; google_color_link = "DE7008"; google_color_url = "E0AD12"; google_color_text = "8B4513"; //-->