所谓企业级应用，通常指面向多用户，包含大量需要持久化的数据，且具有复杂的业务逻辑和领域相关知识的应用。这类应用所涉及的范围十分广泛，包含政府、金融、教育、医疗、电力等大部分行业。
企业级应用用户多、数据量大、业务复杂等特点，导致了其开发和设计变得更为困难，如何设计、构造一个系统，是当前研究的焦点和热点。
本文将从软件系统的广度、深度和变度三个特征量对企业级应用的结构进行简要的分析，阐述该类系统的复杂度产生的原因和这些因素之间的关系。并以此为根据分析各个特征量与系统架构设计之间的关系，论述三种常用企业架构模式：Table Model、Transaction Script和Domain Model的选取原则。
1 系统的特征量
系统的来源是需求，最终的着眼点也是需求，所以系统的分析应该从需求入手。从系统的需求出发，可以将系统的特点描述为三个特征量：广度、深度和变度。
1.1 广度
所谓广度，也可以称之为扁平度，指的是系统需求的种类的个数，狭义的广度指业务实体的数量。比如说一个典型CMS系统，一般会有用户、管理员、文章、文章分类、评论五个业务实体，那么就可以将系统的广度记为5。
很多时候业务实体的划分可能无法做到精确，特别是实体中存在继承时，例如上面提到的CMS系统中，管理员有两个子类：普通管理员和超级管理员，超级管理员重写了父类中CheckPermission方法，以便提供在任何时候都返回True来表示超级管理员具有所有权限（这里只是个例子，实际系统通常使用一个标记来说明超级管理员，并且权限系统通常作为复杂的子系统独立运作）。那么这三个类：管理员、超级管理员普通管理员应该算是三个实体？两个实体？还是一个实体？所以有的时候，我们不会也没有办法明确的表示一个系统的广度是多少，而且仅仅作为一种形象上的认识。
1.2 深度
所谓深度，也可以称之为复杂度，指的是对于系统的每一个需求，它的复杂程度。系统中每一部分的复杂程度是不一致的，可以使用选取系统中的实体作为粒度来分析系统，深度就是这个实体所包含的逻辑的多少和复杂程度。
每一项需求（可以用实体表示，因为需求通常是围绕实体展开的）的复杂度来源于两个方面：自身的业务逻辑和所依赖的实体的复杂度。
深度没有一个具体的指标，只能从形象上理解。仍以上文提到的CMS系统为例，其中文章实体依赖于分类和用户两个实体，涉及的操作有添加、修改、删除、列表、查看、搜索等；而用户实体不依赖于任何实体，涉及的操作有注册和登陆，所以，可以认为文章实体的复杂度高于用户实体。
1.3 变度
系统的需求——无论是客户提供的书面材料还是沟通的结果——通常都是模糊的、具有歧义的。模糊的原因可能是开发人员对该软件面对的领域缺乏经验，也可能是在与客户沟通上存在差异，还有可能，客户对于自身需要的系统并没有一个确切的认识，而只是需要一个程序辅助他的工作并且对这个程序有一些想法，这种现象常见于中小系统以及一些新领域中的系统。
基于这种情况，我们引入变度这个特征量来描述系统需求的不确定程度，变度越大，系统可能发生的改动就越大，系统开发进度就越不平稳；变度越小，系统可能改动的就越小，系统开发进度就越平稳。
从需求相关性看，变度的来源也有两个方面：一是自身的不确定性；二是所依赖实体的不确定性。
需要注意的是，变度是可以被消除的，而广度和深度是来自需求，是固有的。所以在分析典型系统是，暂不考虑引入变度，而将变度较大的系统单独分析。
1.4 特征图
如果将系统的广度作为横坐标，将系统的深度和变度作为纵坐标，那么就可以用两条折线来表示系统的特征，这个图称之为系统的特征图。
图1.1是上例中的CMS系统的特征图。图中的蓝色折线表示深度，红色的折线表示变度。
从图上可以看出，从复杂度的角度来说，文章部分是最高的，而管理员、用户和分章分类则较为简单。对于变度来说，文章分类、文章两者基本一致，其中文章分类的不确定性来自于需求中可能尚未确认的分类层次，而文章的不确定性来自于文章所含信息的不确定性。
图1.1 典型CMS系统的特征图
通常复杂度较高的地方变度也较高，这是显而易见的——复杂的东西更容易存在混淆和不确定性。
2 典型系统
2.1 水平系统
水平系统是指逻辑较为简单，而涉及实体相对较多的系统。
例如，学生信息管理系统可视为典型的水平系统。经划分后的学生数据可能形成多个实体：基本信息、家庭成员信息、素质测评成绩、获奖信息、参加活动信息等。但是这些实体的逻辑都极为简单，都是简单的添加、修改、删除、查看、搜索操作。
这类系统的特征图如图2.1所示。图中所示的只是理想情况，任何系统都不能保证所有的实体复杂程度一致。
图2.1 水平系统的特征图
2.2 垂直系统
垂直系统相较水平系统而言，系统中存在部分实体具有较高的深度，但系统中涉及的实体个数相对较少。
例如企业的财务系统。这类系统中大概包括财务人员、结算单位、明细、报表等实体，且相关的流程和涉及的操作都非常复杂，还经常要求严格的数据完整性和精确性，这些都导致了复杂程度的上升。
另外，此类系统中的实体复杂度的差异通常较大，例如财务人员和结算单位通常只包含数据操作，而明细和报表而有大量的逻辑规则和相互联系。这些原因导致了该类系统的特征图通常会有比较陡峭的曲线。
图2.2是上面提到的财务系统的特征图。
图2.2 垂直系统的特征图
2.3 复杂系统
复杂系统指的系统的广度和深度都很高的系统，也可以认为是垂直系统和水平系统的结合，通常这类系统可以通过划分子系统、划分模块等方法，转化成若干个垂直或水平系统进行处理。
3 架构的选择
3.1 常用架构模式
常用的企业级应用构架可以分为三种：Table Model、Transaction Script和Domain Model。
一、Table Model
Table Model使用记录集作为数据的载体，所有的业务逻辑直接作用在记录集上。
目前大部分开发平台都对记录集有良好的支持，例如JAVA中的ResultSet、.Net中的DataSet等，这些平台对记录集的支持通常覆盖数据库读取直到UI显示的整个生存周期。Table Model可以充分的利用平台的现有组件实现快速开发，这是Table Model的一大优势。
另一方面作为弱类型的记录集没有类型检查，对于复杂逻辑的抽象提供的支持也极为有限，容易产生重复代码，且具有极大的平台相关性和无法令人满意的可测试性。
二、Transaction Script
Transaction Script通常使用简单对象（只包含数据而不包含方法、或者仅包含简单方法的对象）或记录集作为数据的载体，使用Transaction描述业务逻辑。这里的Transaction通常表示逻辑上的事务。
Transaction Script的特点是可以通过抽象将多个实体的功能操作给与统一的实现，且Transaction Script代码的划分十分的明显，非常适合整体水平不高的团队进行协作，团队各成员之间的代码几乎没有交叉。
Transaction Script还可以作为框架形成基础实现，这有利于跨项目的代码复用。
另一方面，Transaction Script架构会形成大量Transaction类和较为复杂的继承体系，这种情况下，经常会存在很多只有细微差别的类似代码，而这些代码本应该使用抽象来消除的。
Transaction Script将数据和操作相分离的设计（Table Model也存在这个问题）有违面向对象的设计原则，当面对复杂的业务逻辑时就会显得相形见绌，也无法很好的利用设计模式等面向对象的方法。
三、Domain Model
Domain Model是完全面向业务逻辑的建模方法，使用面向对象的语言描述系统逻辑，然后在领域模型的基础上构造持久化和UI部分。
Domain Model特别适合与复杂的业务逻辑，可以采用继承、引用和泛型这三类关系描述业务领域的“是”、“有”和“的”，进而描述整个领域模型。各种设计模式可以用于解决常见的设计问题，使模型的设计更加优雅。
但是业务领域为着眼点的Domain Model，在前期通常无法对数据持久化和UI给与足够的关注，这将给后期这两部分的实现增加更多的难度。幸运的是，近年来，类似ORM、和可视化UI设计器等技术的普及，已经使Domain Model的门槛大为降低。
Domain Model对开发成员的要求较高，通常需要所有程序员都有较强的面向对象设计能力。
3.2 架构选取的一般原则
在设计或选取一个架构时，要考虑的问题很多：系统的数据量、系统逻辑复杂程度、开发效率、平台的支持、团队的水平等。但是总体来说，构架设计要遵循一下三个原则：
l 构架能够满足系统的功能。
l 构架应具有一定的弹性。
l 构架应尽量保证开发效率。
满足系统的功能是指系统的结构应该能承载系统设计的数据量和作用在这个数据量上的业务逻辑。千万级的数据和万级的数据显然会使用不同的架构；学生信息管理系统和企业财务系统也会有不同的架构。
架构的弹性是指架构的可扩展性。软件在其生存周期内，肯定会有需求变更的情况出现。架构师必须预测到这种变化，以便其设计的架构必须在一定程度上能够承受这些变化。但对需求的变化不能过度的预计，否则将为系统带来不必要的复杂度，是一种过度设计。
在保证以上两点的情况下，架构的设计要尽量多的利用现有资源和平台，降低开发难度，加快开发进度，节约软件成本。
3.3 典型系统的架构选取
一、水平系统
对于水平系统，不论Table Model、Transaction Script和Domain Model都可以满足系统的要求，但是在外部条件和使用方法上略有不同。
如果所采用的平台没有提供任何辅助的功能，可以尝试采用Transaction Script，该模式对平台的依赖较少，但对人力的成本要求较高。
目前常用的开发平台，例如JAVA EE、.Net，都有内置的记录集支持，甚至覆盖从数据读取到UI显示。从这点来看，Table Model很适合于水平系统。可以通过代码器生成完成大部分的通用代码，通过可视化的界面设计器完成UI的设计。只需要编写少量的验证代码和逻辑代码，就可以获得一个完整的系统。这非常适合于中小型信息管理系统的开发。
采用Domain Model对于水平系统通常会导致过度设计，系统中存在大量的简单对象，而相对于不断重复的添加、修改、删除操作，业务逻辑的分量可以忽略不计。这大大的降低软件的开发效率。使用ORM和代码生成技术可以在一定程度上缓解这个问题，但同时又会导致对开发团队要求的提高，进而导致更高的开发成本。
二、垂直系统
相对与对构架要求比较低的水平系统来说，垂直系统的高复杂度特点使其对架构的要求更为苛刻。
Table Model在这种情况下通常不堪重负。作用在记录集上的业务逻辑代码通常无法抽象，从而使系统中存在大量“神似”的代码，这将导致维护上的灾难；弱类型的记录集不能发挥出编译器类型检验的优势，导致大量的运行时错误；而极差的可测试性使得开发人员在编写复杂逻辑时无法得到反馈，产生走钢丝的感觉。这些都说明了：Table Model不适用于垂直系统。
Transaction Script在一定程度上仍然适用。强类型、抽象、细致的逻辑划分这些都是处理复杂逻辑的良好工具。但是另一方面，无论是按照实体还是按照操作去梳理Transaction复杂的继承体系，都不可避免产生重复的代码，这些代码在需求发生变化或者维护时，将是巨大的负担。
Domain Model在处理复杂的业务逻辑时有独特的优势：专注于业务逻辑的设计很容易编写出直观的、松耦合的、优雅的代码；各种设计模式为各种常见问题提供了现成的解决方案。Domain Model运用强大的面向对象方法，为复杂逻辑提供了良好的解决方案。
但是另一方面，Domain Model确实引入了较高的软件成本。虽然这些成本是作为实现复杂逻辑的必然代价，且随着ORM等技术的成熟和普及不断降低，但架构师在设计和选取系统架构时仍然必须有充分的理由和条件以说明采用Domain Model是必要和可行的。
三、复杂系统
对于复杂系统来说，如果能够将其自然的分解水平系统和垂直系统，那么可以分别使用两种结构。
例如，上文中提到的学生数据管理系统中，如果需要复杂的权限控制，那么可以将系统分解为具有水平系统典型特征的信息管理部分和具有垂直系统典型特征的权限控制部分，两者可以使用不同的架构模式，最终在UI层进行整合。
如果系统不能够自然的分解，那么通常从满足系统功能的原则出发，应优先选择适用于垂直系统的架构模式。而对于大量的基础操作，则使用抽象或者代码生成技术来实现。
3.4 应对变度
应对变度最大的武器是隔离，通过模块之间的解耦合，可以使变度不会产生连锁反应。同时，应该尽量让系统之中变度高的部分依赖于变度低的部分。以下方法将有助于应对变度。
一、沟通
变度的一大来源是交流之中产生的差异，敏捷开发的软件工程学方法鼓励持续不断的沟通，这将从根本上消除变度。
二、使依赖向变度低的方向进行
从变度的来源可以得知，变度将逆着依赖的方向传播。使依赖向变度低的方向的进行，将是防止变度在系统内扩散。例如，相对于具体的实现来说，抽象通常是稳定的。接口、抽象类都属于抽象的范畴，所以在设计的时候通常使实现依赖于共同的抽象，这样的系统更加稳定。
三、重新划分实体范围
通过将实体中变度高的部分和变度低的部分相分离，可以通过增加系统广度的办法隔离变度。例如，某个项目管理系统中，项目的信息包含项目名称、负责人、项目等级、项目分类、项目、项目总经费、项目已到经费等十几个字段的数据，而且已知经费相关的逻辑是复杂的、尚不明确的。那么将项目实体重新划分为项目基本信息和项目经费信息两个实体，将使变度对系统的影响控制在一个更小的范围内。
4 结语
文中提到的典型系统，在实际软件开发过程中并不是严格匹配的，在更多情况下，软件系统具有多方面的特性，所以采用的架构也是多种典型架构模式的结合体。构架的设计人员应该根据具体的情况对软件的架构做相应的调整。
另一方面，在架构的设计中，不仅要考虑软件系统本身，团队的情况、客户的特殊要求、进度安排、成本限制等都应在在设计构架的考虑在内。
本文作者袁冬目前在中国海洋大学计算机系平行与分布式计算实验室就读研究生，从事软件工程和分布式计算的研究。可以通过yuandong1222@gmail.com与他联系。
