0.2 企业应用

很多人编写计算机软件，我们把这些活动都称为软件开发。但是软件的种类是不同的，每种软件都有自身的挑战性和复杂性。我是在与几个电信行业的朋友交谈后，意识到这个问题的。企业应用在某些方面要比电信软件简单得多——多线程问题没有那么困难，无须关注硬件与软件的集成。但是，在某些方面，企业应用又比电信软件更难——企业应用一般都涉及大量复杂数据，而且必须处理很多“不合逻辑”的业务规则。虽然有些技能和模式是适合于所有软件的，但是大多数模式都还只适合某些特定的分支。

我的职业生涯专注于企业应用，因此，这里所谈及的模式也都是关于企业应用的。（企业应用还有一些其他的说法，如“信息系统”或更早期的“数据处理”。）那么，这里的“企业应用”具体指的是什么呢？我无法给出一个精确的定义，但是我可以罗列一些个人的理解。

先举几个例子。企业应用包括工资单、患者记录、发货跟踪、成本分析、信用评分、保险、供应链、会计、客户服务以及外汇交易等。企业应用不包括汽车燃油喷射、文字处理、电梯控制、化工厂控制器、电话交换机、操作系统、编译器以及电子游戏等。

企业应用一般都涉及持久化数据。数据必须持久化是因为程序的多次运行都需要用到它们——实际上，有些数据需要持久化若干年。在此期间，操作这些数据的程序往往会有很多变化。这些数据的生命周期往往比最初生成它们的那些硬件、操作系统和编译器还要长。在此期间，为了存储新的信息而不干扰旧的信息，数据的结构经常会发生许多变化。即使是有根本性的变化发生，或公司安装了一套全新的软件来处理某项任务，这些数据也必须被“迁移”到新的应用上。

企业应用一般都涉及大量数据——一个中等规模的系统往往都包含1GB以上的数据，这些数据是以数千万条记录的方式存在的。巨大的数据量导致数据的管理成为系统的主要工作。早期的系统使用的是索引文件结构，如IBM的VSAM和ISAM。现代的系统往往采用数据库，绝大多数是关系型数据库。设计和填充这些数据库已经成为一个独立的专业领域。

企业应用一般还涉及很多人并发访问数据。对于很多系统来说，人数可能在100人以下，但是对于一些通过互联网进行通信的基于Web的系统，人数则会呈指数级增长。要确保这些人都能够正确地访问数据，就一定会存在这样或那样的问题。即使人数没有那么多，要确保两个人在同时操作同一数据项时不出现错误，也是存在问题的。事务管理工具可以处理其中的一些负担，但是它通常无法做到对应用开发者隐藏。

企业应用还涉及大量操作数据的用户界面屏幕。有几百个用户界面屏幕是不足为奇的。企业应用的用户从偶尔使用到定期使用都有，他们也经常没什么技术背景。因此，出于不同的使用目的，数据需要很多种表现形式。系统一般都有很多批处理过程，但当专注于强调用户交互的用例时，这些批处理过程很容易被忽视。

企业应用很少独立存在，通常需要与散布在企业周围的其他企业应用集成。这些各式各样的系统是在不同时期采用不同技术构建的，甚至连协作机制都不同：COBOL数据文件、CORBA系统或是消息系统。企业经常希望能用一种统一的通信技术来集成所有系统。当然，每次这样的集成工作几乎都很难真正实现，所以会有几个不同的统一集成方案同时存在。当业务组织需要同其业务伙伴进行应用集成时，情况就更糟糕。

即使是某家公司统一了集成技术，它们也还是会遇到业务流程中的差异以及数据中概念的不一致性。一个部门可能认为客户是当前签有协议的人，而另外一个部门可能还要将那些以前有合同但现在已经没有了的人计算在内。再有，一个部门可能只关心产品销售而不关心服务销售。粗看起来，这些问题似乎容易解决，但是，一旦几百条记录中的每个字段都有可能存在着细微差别，问题的规模就会形成不小的挑战——就算唯一知道这些字段真正含义的员工还在公司任职（当然，所有这些都会毫无预警地发生变化）。这样，数据就必须被不停地以各种不同的语法和语义格式读取、转换和写入。

再接下来的问题是由“业务逻辑”带来的。我认为“业务逻辑”这个词很滑稽，因为很难再找出什么东西比“业务逻辑”更加没有逻辑。当我们构建一个操作系统时，总是尽可能地使得系统中的各种事物符合逻辑。而业务规则是人家给你的，没有相当的行政努力，不要想改变它，当然，它们都有自己的理由。你必须面对很多奇怪的条件，而且这些条件相互作用的方式也非常怪异。比如，某个销售人员为了签下其客户几百万美元的一张单，可能会在商务谈判中与对方达成协议，将该项目的年度到账时间推迟两天，因为这样才能够与该客户的账务周期相吻合。成千上万的这类“一次性特殊情况”最终导致了复杂的业务“无逻辑”，使得商业软件开发那么困难。在这种情况下，必须尽量将这些业务逻辑组织成有效的方式，因为我们可以确定的是，这些“逻辑”一定会随着时间不断变化。

对于一些人来说，“企业应用”这个术语指的是大型系统。但是记住这一点很重要：并不是所有的企业应用都是大型的，尽管它们可能都为企业提供巨大的价值。很多人认为，由于小型系统的规模不大，所以不值得为之操心，在某种程度上，这是合理的。如果一个小型系统失败了，它通常不会像大型系统那样引起广泛关注。但是，我认为这种思想没有对小型项目的累积效应给予足够的重视。试想，如果在小型项目上能够进行某些改善措施，那么这种累积效应对企业的影响是非常显著的，特别是因为小型项目通常具有不成比例的价值。实际上，你可以做的最好的事情之一是通过简化架构和过程，将一个大型项目变成小型项目。