下载掌阅APP，畅读海量书库
立即打开
在我们讨论如何设计企业应用以及使用哪些模式之前，认识到这一点很重要：企业应用是多种多样的，不同的问题将导致不同的处理方法。如果有人说，“总是这样做”的时候，就应当敲响警钟了。我认为，设计中最具挑战性（也是我最感兴趣）的地方就是了解有哪些候选的设计方案以及各种不同设计方案之间的优劣比较。进行选择的空间很大，但我在这里只选三个方面。
考虑一个B2C（Business to Customer）的在线零售商：人们浏览和——运气好，还有购物车——购买。这样一个系统必须能够应付大量的用户，因此，其解决方案不但要考虑到资源利用的高效，还要考虑到系统的可伸缩性，以便在用户规模增大时能够通过增加硬件的办法加以解决。这样的应用的领域逻辑可能非常直接：获取订单，进行简单的价格计算和发货计算，给出发货通知。我们希望任何人都能够轻松访问该系统，因此用户界面可以选用通用的Web表现方式，以支持各种不同的浏览器。数据源包括用来存放订单的数据库，还可能包括某种与库存系统的通信交流，以便获得商品的可用性信息和发货信息。
再考虑一个租约自动处理系统。在某些方面，这样的系统比起前面介绍的B2C零售商系统要简单得多，因为它的用户数很少（在特定时间内不会超过100个），但是它的业务逻辑却比较复杂。计算每个租约的月供，处理诸如提早解约和逾期付款这样的事件，签订合同时验证各种数据，这些都是复杂的任务，因为租约行业的许多竞争都是以过去的交易为基础稍加变化而出现的。正是因为规则的随意性很大，才使得像这样一个复杂的业务领域具有挑战性。
这样的系统在用户界面（UI）上也更加复杂。这就要求HTML界面要能提供更丰富的功能和更复杂的屏幕，而这些要求往往是HTML前端目前无法达到的，需要更传统的富客户界面。用户交互的复杂性还会带来事务行为的复杂性：签订租约可能要耗时1～2小时，这期间用户要处于一个逻辑事务中。一个复杂的数据库设计方案中可能也会涉及200多个表以及一些有关资产评估和计价的软件包。
第三个例子是一家小型公司使用的简单的“开支跟踪系统”。这个系统的用户很少，逻辑简单，并且可以通过HTML表示轻松地在整个公司访问，唯一的数据源是数据库中的几个表。尽管如此，开发这样的系统也不是没有挑战。一方面你必须快速地开发出它，另一方面你又必须为它以后可能的发展考虑：也许以后会为它增加计算报销支票的功能，也许它会被集成到工资系统中，也许还要增加关于税务的功能，也许要为公司的CFO生成汇总报表，也许会被集成到一个航空订票Web Service中，等等。如果在这个系统的开发中，也试图使用前面两个例子中的一些架构，可能会影响开发进度。如果一个系统会带来业务效益（如所有的企业应用应该的那样），则系统进度延误同样也是开销。你不希望现在做出的决策会阻碍未来的发展。但是，如果现在就考虑了这些灵活性但是考虑不得当，额外的复杂性又可能会让系统在未来变得更难演化，进一步延误系统部署，减少系统的效益。虽然这类系统很小，但是一个企业中往往有很多这样的系统，这些系统的架构不良性累积起来，后果将会非常可怕。
这三个企业应用的例子都有难点，而且难点各不相同。当然，也不可能有一个适合于三者的通用架构。选择架构时，必须很清楚地理解系统的特定问题，在理解的基础上再来选择合适的设计。本书中也没有一个通用的解决方案。实际上，很多模式仅仅是一些可选方案罢了。即使你选择了特定的模式，也需要修改以满足需要。在构建企业软件时，你不思考是不行的。任何一本书都只是给你提供信息，作为你做决定的基础。
模式是这样，工具也同样如此。在系统开发时应该选取尽可能少的工具，同时也要注意，不同的工具适用于不同的目的。切记不要用错了工具，否则只会事倍功半。