企业应用架构模式

响应性不同于请求处理，它是系统响应请求的速度有多快。这个指标在许多系统里非常重要，因为对于一些系统而言，如果其响应太慢，用户将难以忍受——尽管其响应时间可能不慢。如果能够在处理真正完成之前就给用户一些信息表明系统已经接到请求，则响应性就会好一些。例如，进展条。

一条关于依赖性的普遍原则：领域层和数据源层绝对不要依赖于表现层。

领域逻辑的组织可以分为三种主要的模式：事务脚本、领域模型以及表模块。

事务脚本是这样一个过程：从表示层获得输入、进行校验和计算处理、将数据存储到数据库中以及调用其他系统的操作等。基本的组织方式是让每个过程对应用户可能做的一个动作。所以，我们可以将这一模型想像成一个动作或业务事务的脚本。每一个动作是由一个过程来驱动。

在领域模型中，不再是由一个过程来控制用户某一动作的逻辑，而是由每一个对象都承担一部分相关逻辑。

在许多方面，表模块是事务脚本和领域模型的一个中间地带。它围绕表而非直接围绕过程来组织领域逻辑，提供了更多的结构，而且更容易发现和移除冗余代码。但是，你无法应用许多在领域模型中可以使用的组织细粒度逻辑结构的技术，例如继承、策略和其他面向对象的设计模式。

通常，序列化LOB（大对象Large OBject）对于用来组成应用程序部分的相对独立对象群而言是最好的。但如果过多使用它，最终会把数据库弄得和事务文件系统差不多。

对于任何继承结构，一般都有三种选择。可以为一个层次中的所有类建立一个表，即单表继承；也可以为每个具体类建立一个表，即具体表继承；或者为这个层次中每一个类建立一个表：类表继承。

这三种方法有利有弊。单表继承浪费空间，但避免了连接操作；具体表继承在超类改变时不得不改变所有表，但它也避免了连接操作，允许从一个表取得一个对象；类表继承需要多个连接操作来载入一个对象，这样通常损失了性能，但它是类和表之间最简单的关系。

如果机器处在屏幕流的控制下，那么你就需要应用控制器；如果这台机器是在用户的控制下，你就不要应用控制器。

在视图方面，可以考虑三种模式：转换视图、模板视图和两步视图。

对任何并发程序的本质来说，仅仅考虑正确性是不够的，还必须考虑灵活性（即有多少并发活动可以同时进行）。人们常常需要牺牲一些正确性以获取更多的灵活性，这取决于失败的严重性和可能性以及人们对并发处理数据的需求。

并发问题有两个非常重要的解决方案：一个是隔离（isolation），一个是不变性（immutability）。

在乐观锁和悲观锁之间进行选择的标准是：冲突的频率与严重性。如果冲突很少，或者冲突的后果不会很严重，那么通常情况下应该选择乐观锁，因为它能得到更好的并发性，而且更容易实现。但是，如果冲突的结果对于用户来说是痛苦的，那么就需要使用悲观锁策略。

超时控制和检测机制处理已经出现的死锁，而其他的方法则尽力防止死锁的发生。

跨越多个请求的事务称为长事务。

在请求开始时启动事务，在请求结束时提交事务，这是请求事务。

另一种方法是尽可能晚打开事务。使用延迟事务时，应在事务外完成读取数据的操作，只在修改数据的时候启动事务。然而，这可能会导致不一致读问题。

当可以并发执行并且结果与以某种顺序依次执行的结果相同时，事务就是可串行化的（serializable）。

如果系统中有很多用户，应该考虑使用集群来提高吞吐率。会话迁移（session migration） 允许一次会话从一台服务器转移到另一台服务器，从而可以由一台服务器处理一个请求，其他服务器处理其他的请求。与其相反的方式是服务器亲和（server affinity），它要求某次特定会话的所有请求只能由同一台服务器处理。

分布对象设计第一定律：不要分布使用对象。