一则惋惜的案例――软件层次结构与业务模型

 

前几年,有幸接触到一个IT企业，一个在软件开发行业做了近七年的企业，一直以来开发HIS医院综合管理系统，从最初的第一个版本开始一直沿用着传统的软件开发思想和模式，软件结构基本上没有作层次划分，将绝大部分程序代码集中在界面单元中，即智能UI。今天，也许还有人信奉智能UI在软件开发中的优势，毕竟在前几年国内很多软件是这样做出来的。但是，智能UI也是软件生命周期中的毒瘤，可以加速软件产品的消亡，令人痛苦不堪。

在HIS刚开发出来的时候，尽管使用了智能UI，但系统结构还是比较清晰的：如对整个系统做了模块划分，由多个子系统组成等。很快就有一两个客户在使用，系统运行稳定，客户评价也比较满意。换言之，一个企业应付一两个客户还是绰绰有余的。而随着市场的发展，客户的不断增多，需求的不断变化，促使企业不断招兵买马，扩充开发队伍。而此时正是危机四伏的时候，犹如在隐埋着一颗颗定时炸弹。由于使用智能UI，导致同样一个功能在多个模块中出现，同一条SQL语句，同一个业务规则在多个代码单元中出现。而且开发人员独立负责开发的模式，更加重同样一个东西在不同的地方以不同的方式出现的影响等。在一个代码单元中，UI代码、业务逻辑代码、状态控制代码、数据处理代码全都混在一起，牵一发而动全身。这个代码单元几年下来，不管有用的还是没有用的代码，不管是有用的函数还是没用的函数，或者是经过很多人之手的编码习惯都积累下来了，代码变得复杂、臃肿不堪，慢慢的，这个代码单元的功能和结构变得模糊而不被人理解。当客户操作一个功能的时候，谁也理不清代码在如何运作，即使代码在调试状态下，调来调去的代码让我们马上就会晕倒，无从下手。而另一方面，客户的需求在不断增长和不断变化，改动一个功能点牵连太深不可预测，需要大动干戈，势必使开发维护陷入焦油坑。导致客户的需求和要求迟迟得不到回复，即使满足了伴随也带来更多的错误。

尽管这套系统慢慢变得难于理解，近七年下来，前后也有上百家客户。但不幸的是，企业越来越难做。由于软件质量和维护跟不上客户的需求，医院管理难以正常运行，很多客户迫于无奈纷纷换成了其他软件企业的HIS系统。后来业务逐渐萎缩令人惋惜。

此后，我也一直在思考这样一个问题，是什么让一个有着近七年历史和上百家客户经历的企业如此难堪，这样的案例不是个案，究其原因是多方面的，就软件开发本身就远比我们想象复杂的多。单从软件框架方面来说，整个系统没有一个很好的层次结构。一个复杂的系统必须具备一个良好的层次来分离关注点，避免所有的东西混在一起，很难阅读和理解，避免对UI的简单改动影响业务逻辑，改动业务逻辑又需要小心翼翼的跟踪UI代码、数据库代码或者其他的程序元素。

软件行业普遍使用的软件层次结构大致分为以下四层。

 

用户界面层（表示层）：负责向用户显示信息，并且解析用户命令，括外部系统的命令。

应用层：定义软件可以完成的工作，并且指挥具有丰富含义的领域对象来解决问题。这个层要保持简练，它不包含处理业务规则，只给下层领域对象协调任务、委托工作。在这个层不反映业务情况的状态，但反映用户或程序的任务进度和状态。

 

业务领域层（模型层）：负责表达业务概念、业务状况及业务规则，这一层是软件的核心，反映一个软件企业所掌握的行业知识和业务经念水平。由于HIS系统没有这一层，七年丰富的行业特性和业务经验没有载体，业务模型得不到沉淀，这也是HIS系统做了七年难于维持的重要原因。

基础服务层：为上层提供通用的技术和服务：应用消息的发送和ORM机制，数据存取等。

严格意义来说，同层的所有元素只能依赖本层或者其直接下层的元素，向上的信息传递必须通过间接机制进行，如MVC模式。目前网络开发中很多成熟的软件开发架构如MVC框架：Struts、EasyJWeb、MonoRail，ORM框架：Hibernate、IBatis.Net，IOC容器：Spring、Castle等，都为软件开发搭建了一个良好的框架，将各个层次进行分离，促使软件开发越来越关注业务模型。

由于有效的将各个层次进行分离，每一层只关注本层的程序元素，使得各层次得到更好的设计，使得同层的各个程序元素得到更好的聚合，减少与其他层次程序元素的连接牵连，提高了软件的质量。

       同时，在具体的软件项目中，这四个层次也许并不是都必须的，但业务领域层是不可或缺的。没有业务模型，行业知识和行业经验得不到集中体现，我们的软件将是一片散沙，没有灵魂。