先举几个例子。企业应用包括工资单、患者记录、发货跟踪、成本分析、信用评分、保险、供应链、会计、客户服务以及外汇交易等。企业应用不包括汽车燃油喷射、文字处理、电梯控制、化工厂控制器、电话交换机、操作系统、编译器以及电子游戏等。
企业应用一般都涉及持久化数据。数据必须持久化是因为程序的多次运行都需要用到它们——实际上，有些数据需要持久化若干年。在此期间，操作这些数据的程序往往会有很多变化。这些数据的生命周期往往比最初生成它们的那些硬件、操作系统和编译器还要长。在此期间，为了存储新的信息而不干扰旧的信息，数据的结构经常会发生许多变化。即使是有根本性的变化发生，或公司安装了一套全新的软件来处理某项任务，这些数据也必须被“迁移”到新的应用上。
企业应用一般都涉及大量数据——一个中等规模的系统往往都包含1GB以上的数据，这些数据是以数千万条记录的方式存在的。巨大的数据量导致数据的管理成为系统的主要工作。早期的系统使用的是索引文件结构，如IBM的VSAM和ISAM。现代的系统往往采用数据库，绝大多数是关系型数据库。设计和填充这些数据库已经成为一个独立的专业领域。
企业应用一般还涉及很多人并发访问数据。对于很多系统来说，人数可能在100人以下，但是对于一些通过互联网进行通信的基于Web的系统，人数则会呈指数级增长。要确保这些人都能够正确地访问数据，就一定会存在这样或那样的问题。即使人数没有那么多，要确保两个人在同时操作同一数据项时不出现错误，也是存在问题的。事务管理工具可以处理其中的一些负担，但是它通常无法做到对应用开发者隐藏。
企业应用还涉及大量操作数据的用户界面屏幕。有几百个用户界面屏幕是不足为奇的。企业应用的用户从偶尔使用到定期使用都有，他们也经常没什么技术背景。因此，出于不同的使用目的，数据需要很多种表现形式。系统一般都有很多批处理过程，但当专注于强调用户交互的用例时，这些批处理过程很容易被忽视。
企业应用很少独立存在，通常需要与散布在企业周围的其他企业应用集成。这些各式各样的系统是在不同时期采用不同技术构建的，甚至连协作机制都不同：COBOL数据文件、CORBA系统或是消息系统。企业经常希望能用一种统一的通信技术来集成所有系统。当然，每次这样的集成工作几乎都很难真正实现，所以会有几个不同的统一集成方案同时存在。当业务组织需要同其业务伙伴进行应用集成时，情况就更糟糕。
即使是某家公司统一了集成技术，它们也还是会遇到业务流程中的差异以及数据中概念的不一致性。一个部门可能认为客户是当前签有协议的人，而另外一个部门可能还要将那些以前有合同但现在已经没有了的人计算在内。再有，一个部门可能只关心产品销售而不关心服务销售。粗看起来，这些问题似乎容易解决，但是，一旦几百条记录中的每个字段都有可能存在着细微差别，问题的规模就会形成不小的挑战——就算唯一知道这些字段真正含义的员工还在公司任职（当然，所有这些都会毫无预警地发生变化）。这样，数据就必须被不停地以各种不同的语法和语义格式读取、转换和写入。
再接下来的问题是由“业务逻辑”带来的。我认为“业务逻辑”这个词很滑稽，因为很难再找出什么东西比“业务逻辑”更加没有逻辑。当我们构建一个操作系统时，总是尽可能地使得系统中的各种事物符合逻辑。而业务规则是人家给你的，没有相当的行政努力，不要想改变它，当然，它们都有自己的理由。你必须面对很多奇怪的条件，而且这些条件相互作用的方式也非常怪异。比如，某个销售人员为了签下其客户几百万美元的一张单，可能会在商务谈判中与对方达成协议，将该项目的年度到账时间推迟两天，因为这样才能够与该客户的账务周期相吻合。成千上万的这类“一次性特殊情况”最终导致了复杂的业务“无逻辑”，使得商业软件开发那么困难。在这种情况下，必须尽量将这些业务逻辑组织成有效的方式，因为我们可以确定的是，这些“逻辑”一定会随着时间不断变化。
对不同的领域逻辑组织方式，领域逻辑的复杂度和工作量之间的关系示意
对于一些人来说，“企业应用”这个术语指的是大型系统。但是记住这一点很重要：并不是所有的企业应用都是大型的，尽管它们可能都为企业提供巨大的价值。很多人认为，由于小型系统的规模不大，所以不值得为之操心，在某种程度上，这是合理的。如果一个小型系统失败了，它通常不会像大型系统那样引起广泛关注。但是，我认为这种思想没有对小型项目的累积效应给予足够的重视。试想，如果在小型项目上能够进行某些改善措施，那么这种累积效应对企业的影响是非常显著的，特别是因为小型项目通常具有不成比例的价值。实际上，你可以做的最好的事情之一是通过简化架构和过程，将一个大型项目变成小型项目。
2.企业应用的种类
在我们讨论如何设计企业应用以及使用哪些模式之前，认识到这一点很重要：企业应用是多种多样的，不同的问题将导致不同的处理方法。如果有人说，“总是这样做”的时候，就应当敲响警钟了。我认为，设计中最具挑战性（也是我最感兴趣）的地方就是了解有哪些候选的设计方案以及各种不同设计方案之间的优劣比较。进行选择的空间很大，但我在这里只选三个方面。
考虑一个B2C（Business to Customer）的在线零售商：人们浏览和——运气好，还有购物车——购买。这样一个系统必须能够应付大量的用户，因此，其解决方案不但要考虑到资源利用的高效，还要考虑到系统的可伸缩性，以便在用户规模增大时能够通过增加硬件的办法加以解决。这样的应用的领域逻辑可能非常直接：获取订单，进行简单的价格计算和发货计算，给出发货通知。我们希望任何人都能够轻松访问该系统，因此用户界面可以选用通用的Web表现方式，以支持各种不同的浏览器。数据源包括用来存放订单的数据库，还可能包括某种与库存系统的通信交流，以便获得商品的可用性信息和发货信息。
再考虑一个租约自动处理系统。在某些方面，这样的系统比起前面介绍的B2C零售商系统要简单得多，因为它的用户数很少（在特定时间内不会超过100个），但是它的业务逻辑却比较复杂。计算每个租约的月供，处理诸如提早解约和逾期付款这样的事件，签订合同时验证各种数据，这些都是复杂的任务，因为租约行业的许多竞争都是以过去的交易为基础稍加变化而出现的。正是因为规则的随意性很大，才使得像这样一个复杂的业务领域具有挑战性。
这样的系统在用户界面（UI）上也更加复杂。这就要求HTML界面要能提供更丰富的功能和更复杂的屏幕，而这些要求往往是HTML前端目前无法达到的，需要更传统的富客户界面。用户交互的复杂性还会带来事务行为的复杂性：签订租约可能要耗时1～2小时，这期间用户要处于一个逻辑事务中。一个复杂的数据库设计方案中可能也会涉及200多个表以及一些有关资产评估和计价的软件包。
第三个例子是一家小型公司使用的简单的“开支跟踪系统”。这个系统的用户很少，逻辑简单，并且可以通过HTML表示轻松地在整个公司访问，唯一的数据源是数据库中的几个表。尽管如此，开发这样的系统也不是没有挑战。一方面你必须快速地开发出它，另一方面你又必须为它以后可能的发展考虑：也许以后会为它增加计算报销支票的功能，也许它会被集成到工资系统中，也许还要增加关于税务的功能，也许要为公司的CFO生成汇总报表，也许会被集成到一个航空订票Web Service中，等等。如果在这个系统的开发中，也试图使用前面两个例子中的一些架构，可能会影响开发进度。如果一个系统会带来业务效益（如所有的企业应用应该的那样），则系统进度延误同样也是开销。你不希望现在做出的决策会阻碍未来的发展。但是，如果现在就考虑了这些灵活性但是考虑不得当，额外的复杂性又可能会让系统在未来变得更难演化，进一步延误系统部署，减少系统的效益。虽然这类系统很小，但是一个企业中往往有很多这样的系统，这些系统的架构不良性累积起来，后果将会非常可怕。
这三个企业应用的例子都有难点，而且难点各不相同。当然，也不可能有一个适合于三者的通用架构。选择架构时，必须很清楚地理解系统的特定问题，在理解的基础上再来选择合适的设计。
3.企业架构模式
模式的概念早就有了。我在这里不想把这段历史重新演绎一遍。只是想简单谈谈我对模式和它们为什么是描述设计的重要手段的一些看法。
模式没有统一的定义，可能最好的起点是Christopher Alexander给出的定义（这也是许多模式狂热者的灵感来源）：
“每一个模式描述了一个在我们周围不断重复发生的问题以及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”[Alexander et al.]。
尽管Alexander是建筑家，他谈论的是建筑模式，但其定义也能很好地适用于软件业。模式的核心就是特定的解决方案，它有效而且有足够的通用性，能解决重复出现的问题。模式的另一种视角是把它看成一组建议，而创造模式的艺术则是将很多建议分解开来，形成相互独立的组，在此基础上可以相对独立地讨论它们。
模式的关键点是它们源于实践。必须观察人们的工作过程，发现其中好的设计，并找出“这些解决方案的核心”。这并不是一个简单的过程，但是一旦发现了某个模式，它将是非常有价值的。
一旦需要使用模式，就必须知道如何将它运用于当前的问题。使用模式的关键之一是不能盲目使用，这也是模式工具为什么都那么惨。我认为模式是一种“半生不熟品”，为了用好它，还必须在自己的项目中把剩下的那一半“火候”补上。我本人每次在使用模式时，都会东改一点西改一点。因此你会多次看到同一个解决方案，但没有一次是完全相同的。
每个模式相对独立，但又不彼此孤立。有时候它们相互影响，如影随形。
