整本书中，我印象最为深刻的就是作者对于远程外观的讲解，在《远程外观》这一章节中，作者提到：“任何对象可能作为远程对象使用时，时常需要一个粗粒度的接口来减少完成某些任务所需要的调用次数。这不仅会影响你的方法调用，同样还会影响你的对象。现在，一个调用中就会包括访问和更改订单及订单的功能，而不会像以前那样分开调用，这会完全影响你的对象结构。你将不得不放弃小粒度对象和小粒度方法带来的清晰意图和小粒度控制所带来的好处。编程变得困难，并且会使生产率下降。”，足以见得，作者通俗语言下的真诚，分布式对象意味着粗粒度的调用，Ajax是一个例子，跟前段工程师协作时，总是尽可能地把尽可能多的数据塞到一个响应里。对此，作者还说：“一个远程外观是一个粗粒度的外观，它建立在大量的细粒度对象之上。所有细粒度对象都没有远程接口，并且远程外观不包括领域逻辑。远程外观所要完成的功能是把粗粒度的方法转换到底层的细粒度对象上。任何外观都应该是一层薄薄的皮肤并且只负责很小一部分责任。”也就是说，对restful服务而言，Facade对应着Controller这一层。这与计算机网络上的简化终端，似乎有异曲同工的地方。关于远程外观，作者是这样总结的，“远程外观这种模式意味着同步”。
不止是远程外观，整本书把数据库对象关系、事务、并发、领域模型、MVC等等知识都讲得很是详细而深入。
关于企业应用的种类。在讨论如何设计企业应用以及使用哪些模式之前，明确这样一个观点是非常重要的，即企业应用是多种多样的，不同的问题将导致不同的处理方法。设计中最具挑战性的地方就是了解有哪些候选的设计方法以及各种不同设计方法之间的优劣比较。进行选择的控件很大，考虑一个B2C（Business to Customer）的网上零售商：人们通过浏览器浏览，通过购物车购买商品。通过购物车购买商品。这样一个系统必须能够应付大量的客户，因此，其解决方案不但要考虑到资源利用的有效性，还要考虑到系统的可伸缩性，以便在用户规模增大时能够通过增加硬件的办法加以解决。该系统的业务逻辑可以非常简单：获取订单，进行简单的价格计算和发货计算，给出发货信息。我们希望任何人都能够访问该系统，因此用户界面可以选用通用的Web表现方式，以支持各种不同的浏览器。数据源包括用来存放订单的数据库，还可能包括某种与库存系统的通信交流，以便获得商品的可用性信息和发货信息。再考虑一个租约合同自动处理系统。在某些方面，这样的系统比起前面介绍的B2C系统要简单，因为它的用户数很少（在特定时间内不会超过100个），但是它的业务逻辑却比较复杂。计算每个租约的月供，处理如提早解约和延迟付款这样的事件，签订合同时验证各种数据，这些都是非常复杂的任务，因为租约领域的许多竞争都是以过去的交易为基础稍加变化而出现的。正是因为规则的随意性很大，才使得像这样一个复杂领域具有挑战性。这样的系统在用户界面（UI）上也很复杂。这就要求HTML界面要能提供更丰富的功能和更复杂的屏幕，而这些要求往往是HTML界面目前无法达到的，需要更常规的客户界面。用户交互的复杂性还会带来事务行为的复杂性：签订租约可能要耗时1~2个小时，这期间用户要处于一个逻辑事务中。一个复杂的数据库设计方案中可能也会涉及到200多个表以及一些有关资产评估和计价的软件包。第三个例子是一家小型公司使用的简单的“开支跟踪系统”。这个系统的用户很少，功能简单，通过HTML表现方式可以很容易实现，涉及的数据源表项也不多。尽管如此，开发这样的系统也不是没有挑战。一方面你必须快速地开发出它，另一方面你又必须为它以后可能的发展考虑；也许以后会为它增加赔偿校验的功能，也许它会被集成到工资系统中，也许还要增加关于税务的功能，也许要为公司的CFO生成汇总报表，也许会被集成到一个航空订票Web Service中，等等。如果在这个系统的开发中，也试图使用前面两个例子中的一些架构，可能会影响开发进度。如果一个系统会带来业务效益，则系统进度延误同样也是开销。如果现在不做决策又有可能影响系统未来的发展。但是，如果现在就考虑了这些灵活性但是考虑不得当，额外的复杂性又可能会影响到系统的发展，进一步延误系统部署，减少系统的效益。虽然这类系统很小，但是一个企业中往往有很多这样的系统，这些系统的架构不良性累积起来，后果将会非常可怕。这三个企业应用的例子都有难点，而且难点各不相同。当然，也不可能有一个适合于三者的通用架构。选择架构时，必须很清楚地了解面临的问题，在理解的基础上再来选择合适的设计。实际上，很多模式仅仅是一些可选方案罢了。即使选择了某种模式，也需要进一步根据面临的问题来修改模式。在构建企业应用时，不思考是不行的。所有书本知识只是提供信息，作为决定的基础。模式是这样，工具也同样如此。在系统开发时应该选取尽可能少的工具，不同的工具擅长处理的方面也不同。
关于性能的考虑。很多架构的设计决策和性能有关。对于大多数与性能相关的问题，首先应该建立系统，调试运行，然后通过基于测量的严格的优化过程来提高性能。但是，有一些架构上的决策对性能的影响，可能是后期优化难以弥补的。而且即使这种影响可以在后期很容易地弥补，参与这个项目的人们仍然会从一开始就担心这些决策。这是因为“眼见为实”：所有那些关于性能的条条框框，不在具体系统中配置运行一下，是很难有说服力的。在系统中，需要自行决定是否进行性能优化。在做性能优化后，一定要与优化前进行测量对比，以确定真的得到了优化，否则，可能只是破坏了代码的可读性。还有一个很重要的推论：配置上的重大变化会使得某些性能优化失效。因此，在升级虚拟机、硬件、数据库或其他东西到新的版本时，必须重新确认性能优化工作的有效性。很多情况下，配置变更都会对性能优化有影响，有时候会出现以前为了提升性能做的优化，在新环境下居然影响性能。关于性能的另一个问题是很多术语的使用不一致。最明显的例子就是“可伸缩性”（scalability），它可能有6-7种含义。响应时间是系统完成一次外部请求处理所需要的时间。这些外部请求可能是用户交互行为，例如按下一个按钮，或是服务器API调用。响应性不同于请求处理，它是系统响应请求的速度有多快。这个指标在许多系统里非常重要，因为对于一些系统而言，如果其响应性太慢，用户将难以忍受，尽管其响应时间可能不慢。如果在请求处理期间，系统一直处于等待状态，则系统的响应性和响应时间是相同的。然而，如果能够在处理真正完成之前就给用户一些信息表明系统已经接到请求，则响应性就会好一些。例如，在文件拷贝过程中，为用户提供一个“进度条”，将会提高用户界面的响应性，但并不会提高响应时间。等待时间是获得系统任何形式响应的最小时间，即使应该做的工作并不存在。通常它是远程系统中的大问题。假设程序什么都不做，只是调用返回即可，则如果在本机上运行程序，一般都会立即得到响应。但是，如果在远程计算机上运行程序，情况就不一样，往往需要数秒的时间才能得到响应。因为从发出请求到得到响应的数秒时间主要用于排除使信息在线路上传输的困难。应用开发者对等待时间无能为力，这也是为什么要尽量避免远程调用的原因。吞吐率是给定时间内能够处理多大的请求量。如果考察的是文件拷贝，则吞吐率可以用每秒字节量来表示。对于企业应用来说，吞吐率通常用每秒事务数（tps）来度量。这种方法的一个问题是指标依赖于事务的复杂程度。对于特定系统的测试，应该选取普通的事务集合。在这里，性能或指吞吐率，或者指响应时间，由用户自己决定。当通过某种优化技术后，使得系统的吞吐率提高了，但是响应时间下降了，这时就不好说系统的性能提高了，最好用更准确的术语表示。从用户角度而言，响应性往往比响应时间更重要，因此，为了提高响应性而损失一些响应时间或者吞吐率是值得的。负载是关于系统当前负荷的表述，也许可以用当前有多少用户与系统相连来表示。负载有时也作为其他指标（如响应时间）的背景。因此，我们可以说：在10个用户的情况下，请求响应时间是0.5秒，在20个用户的情况下，请求响应时间是2秒。负载敏感度是指响应时间随负载变化的程度。假设：系统A在10~20个用户的情况下，请求响应时间都是0.5秒；系统B在10个用户的情况下，请求响应时间是0.2秒，在20个用户的情况下，请求响应时间上升到2秒。此时，系统A的负载敏感度比系统B低；我们还可以使用术语衰减（degradation），称系统B衰减得比系统A快。效率是性能除以资源。如果一个双CPU系统的性能是30tps，另一个系统有4个同样的CPU，性能是40tps，则前者效率高于后者。系统的容量是指最大有效负载或吞吐率的指标。它可以是一个绝对最大值或性能衰减至低于一个可接受的阈值之前的临界点。可伸缩性度量的是向系统中增加资源（通常是硬件）对系统性能的影响。一个可伸缩性的系统允许在增加了硬件后，能够有性能上的合理提高。例如，为了使吞吐率提高一倍，要增加多少服务器等。垂直可伸缩性或称垂直延展，通常指提高单个服务器的性能，例如增加内存。水平可伸缩性或称水平延展，通常指增加服务器的数目。问题是，设计决策对所有性能指标的作用并不相同。比如，某个服务器上运行着两个软件系统：Swordfish的容量是20tps，而Camel的容量是40tps。哪一个的性能更高？哪一个的可伸缩性好？仅凭这些数据，无法回答关于可伸缩性的问题，只能说Camel系统在单片机上的效率更高。假设又增加了一台服务器后，我们发现：Swordfish的容量是35tps，Camel的容量是50tps。尽管Camel的容量仍然大于Swordfish，但是后者在可伸缩性上却显得比前者更好。假设继续增加服务器数目后发现：Swordfish每增加一台服务器提高15tps，Camel每增加一台服务器提高10tps。在获得了这些数据后，才可以说，Swordfish的水平可伸缩性比Camel好，尽管Camel在5个服务器以下会有更好的效率。当构建企业应用系统时，关注硬件的可伸缩性往往比关注容量或效率更重要。如果需要，可伸缩性可以给予你获得更好性能的选择，可伸缩性也可以更容易实现。有时，设计人员费了九牛二虎之力才提高了少许容量，其开销还不如多买一些硬件。换句话说，假设Camel的费用比Swordfish高，高出的部分正好可以买几台服务器，那么选择Swordfish可能更合算，尽管你目前只需要40tps。现在人们经常抱怨软件对硬件的依赖性越来越大，有时为了运行某些软件就不得不对硬件进行升级，就像我一样，为了用最新版本的Word，就必须不断地升级笔记本电脑。但是总的来说，购买新硬件还是比修改旧软件来得便宜。同样，增加更多的服务器也比增加更多的程序员来得便宜——只要你的系统有足够的可伸缩性。
作者的观察力，那种善于从司空见惯的日常现象中发现秩序的能力，同样让我钦佩并受益匪浅。