《企业应用架构模式》的原文摘录
任何对象可能作为远程对象使用时，经常需要一个粗粒度的接口来减少完成某些任务所需要的调用次数。这不仅会影响你的方法调用，同样还会影响你的对象。现在，一个调用中就会包括访问和更改订单及订单的功能，而不会像以前那样分开调用，这会完全影响你的对象结构。你将不得不放弃小粒度对象和小粒度方法带来的清晰意图和小粒度控制所带来的好处。编程变得困难，并且会使生产率下降。 (查看原文 )
一个远程外观是一个粗粒度的外观（facade），它建立在大量的细粒度对象之上。所有细粒度对象都没有远程接口，并且远程外观不包括领域逻辑。远程外观所要完成的功能是把粗粒度的方法转换到低层的细粒度对象上。
任何外观都应该是一层薄薄的皮肤并且只负责很小一部分责任。 (查看原文 )
远程外观这种模式意味着同步。 (查看原文 )
为别人提供服务的接口和使用别人服务的接口存在较大的差别，需要明确区分。这就是表现层和数据层相对于核心的本质差别 (查看原文 )
合并了行为和数据的领域的模型。
领域模型衍生出两种风格。简单领域模型看起来和数据库设计很类似，这种设计中几乎每一个数据库表都与一个领域对象对应。而复杂领域模型则与数据库设计不同，它使用继承、策略和其他设计模式，是一张由互联的细粒度对象组成的复杂网络。复杂领域模型更适合复杂的逻辑，但它到数据库的映射比较困难。简单领域模型可以使用活动记录，而复杂领域模型需要使用数据映射器。 (查看原文 )
对于任何并发的本质来说，仅仅考虑正确性是不够的，还必须考虑灵活性（即有多少并发活动可以同时进行）。人们常常需要牺牲一些正确性以获取更多的灵活性，这取决于失败的严重性和可能性以及人们对并发处理数据的需求。 (查看原文 )
依我们看来，使用每会话一进程有很多可说之处。尽管每会话一进程没有每会话一线程的效率高，但它们有相同的可伸缩性。而且有更好的健壮性——如果某个现成崩溃了，可能会导致整个进程垮掉，但是使用每会话一进程能限制这种破坏。特别是对经验较少的开发者们，用硬件代价来避免处理线程的麻烦（包括修复bug所用的时间和代价）是值得的。事实上，很少有人真正做过性能测试来估算他们在应用中使用每会话一线程和每会话一进程的代价。 (查看原文 )
10.4 数据映射器(Data Mapper)
在保持对象和数据库(以及映射器本身)彼此独立的情况下在二者之间移动数据的一个映射层。
对象和关系数据库用来组织数据的机制不同。对象很多部分（如集合和继承）在关系数据库中不存在。当创建一个具有大量业务逻辑的对象模型时，有必要采用这些机制更好地组织它的数据和行为。如此一来便产生了不同的方案，也就是说对象方案和关系方案不相配。
数据映射器时分离内存对象与数据库的一个软件层。其职责时在内存对象与数据库之间传递数据并保持它们彼此独立。有了数据映射器，内存对象甚至不需要知道数据库的存在；它们也不需要SQL接口代码，当然也不需要知道数据库方案。
数据映射器的主要优点是无论是在设计阶段、开发阶段、还是测试阶段、在领域模型上操作时可以不考虑数据库。领域对象对数据库的结构一无所知，因为所有这些对应关系都由数据映射器完成。 (查看原文 )
模式描述在我们周围不断重复发生的问题，以及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。
——Christopher Alexander
企业应用在某些方面比其他软件复杂得多（如电信通信软件）：纷繁复杂的企业数据、“不合逻辑”的业务规则、变化莫测的用户需求，等等。
模式的关键点在于它们源于实践。必须观察人们的工作过程，发现其中好的设计，并找出‘这些解决方案的核心’。这不是一个简单的过程，但是一旦发现了某个模式，它将是非常有价值的。 (查看原文 )
构建计算机系统并非易事。随着系统复杂性的增大，构建相应软件的难度将呈指数增大。 (查看原文 )
最好是通过简化架构和过程，将一个大型项目简化成小型项目。 (查看原文 )
他认为，架构是一种主观上的东西，是专家级项目开发人员对系统设计的一些可共享的理解。
即使是某个企业统一了集成技术，它们也还是会遇到业务过程中的差异以及数据概念的不一致性。
我认为“业务逻辑”这个词很滑稽，因为很难再找出什么东西比“业务逻辑”更加没有逻辑。
在文件拷贝过程中，为用户提供一个“进度条”，将会提高用户界面的响应性，但并不会提高响应时间。 (查看原文 )
层次并不能封装所有东西，有时它会为我们带来级联修改。
20世纪90年代，随着 C/S 系统的出现，分层的概念更明显了... 问题来自领域逻辑：如业务规则、验证、计算等。通常，人们会把它们写在客户端，但是这样很笨拙，并且往往把领域逻辑直接嵌入到用户界面。... 另一种办法是把这些领域逻辑放到数据库端，作为存储过程。 (查看原文 )
当人们讨论分层时，常常不容易区分 layer 和 tier。... tier 意味着物理上的分离。客户/服务器系统通常被称为 "Two Tier System。"
以下因素被 Jens Coldewey 称为复杂性增压器（Complexity Booster）：分布、显式多线程、范型差异（例如对象/关系）、多平台开发以及极限性能要求。 (查看原文 )
ActiveRecord 就是从行数据入口开始，把领域逻辑加到类中。 (查看原文 )
关系数据库的映射开销大概是程序开发总开销的 1/3。
现代的系统允许把引用完整性检查延迟到交互结束的时候进行。如果有这个能力，没有道理不使用它。 (查看原文 )
细粒度接口不能很好地用在远程调用中。.... 当在多个类上应用分布式策略时，最终得到的系统有许多的远程调用，从而需要繁琐的粗粒度接口。 (查看原文 )
分布式对象设计第一定律：不要分布使用对象。
在设计系统时必须尽可能限制分布边界。... 最困难的地方在于：要保证结果不会产生太多的远程调用。
我认为在 Web Service 中更适合使用异步方式。 (查看原文 )
.NET 大力宣传的是 Web Services，但是我不会在一个应用程序内部使用 Web Services，而只会像在 Java 中一样，使用它们作为一种允许应用集成的表现层。
在我撰写本书时，专家们关于 Web Services 比较一致的观点是：它使得重用成为现实，并最终导致系统集成商的消失。但是我对此持谨慎态度。Web Services 在本书介绍的这些模式中发挥不了太大的作用，因为 Web Services 是应用集成而不是应用构建的技术。 (查看原文 )
很多方面，数据传输对象都是我们被告知永远不要写的对象之一。它经常只不过是一堆字段及它们的 getter 和 setter 方法。这种对象的价值在于允许你在一次调用中传输几部分的信息，这是分布式系统的本质。 (查看原文 )
