martin fowler老爷子的《企业应用架构模式》一书在江湖上流传已久，在十几年前就企业应用中的典型场景及设计模式进行了思考和总结，可以看到书中提及的常用模式在如今流行的企业应用框架中已经落地。近日拜读，受益不少，将一些感悟和共鸣记录下来，整理下，不全面也不深入，只便于后续乱翻书。
写在前面行文知其思维，martin老爷子的书写起来条理清晰，层次分明，易于理解，非常值得称道，本文借鉴martin先生的行文模式，每一种模式均包含如下几部分：模式概要、我的理解、项目实践。希望通过后面两部分的介入，尝试将对应要点落地。
知识概要该书第一部分“表述”对书中提及的各种模式及知识要点做了概括性介绍。主要从抽象层面介绍了企业应用中遇到的架构问题及常见的解决思路。涉及到：分层架构思想、领域逻辑组织、orm、web表现层、并发、会话状态及管理、分布式相关等。
企业应用企业应用时将计算机技术这一生产力作用于现实世界的表现形式。一个企业应用的设计需要考虑清楚该应用的业务目标、受众人群等。企业应用一般有如下特点：
需要持久化数据。采用何种持久化介质？如何持久化？
涉及大量数据。数据存取的高效性？数据容量？存储介质如何支持数据的快速增长？
多人同时访问数据。并发问题？服务可用性？用户会话管理？
大量用户交互。交互方式？服务可用性？
同其他企业应用之间的集成。系统集成形式？如何降低耦合？快速集成？
斜线部分是我想到的一些关注点。
架构关于“架构”的定义，众说纷纭，martin认为可以统一的两点有：
最高层次的系统分解；
系统中不易改变的决定。
在不同人看来，在不同的上下文下，在不同的系统生命周期时，对于“架构”的理解是不一样的。重要的是能够因时因地地选择合适的架构模式和设计。
分层通常将系统分为多层，层与层之间约定好契约，下层对上层按照契约提供服务。
分层是最经典也是最常见的一种架构思想，在网络协议的设计中，在应用系统的架构设计中，都使用到了分层的设计思想。
分层可以带来如下好处可以概括为：层内部内聚，层之间解耦。层内部的内聚可以专注于本层的核心逻辑，层之间解耦，降低层与层之间的耦合，可以替换其中某一层的实现而不对其他层产生副作用。
分层同样可能带来副作用：人为引入的“分层”会给开发增加一定工作量，同时可能带来一定的性能损耗。
我的理解：“分层”及其他架构模式都是人为引入的，目的是为了让人更好地理解和维护程序和系统。对于计算机而言，它进行资源分配和调度的单位是进程，它只知道有多少个进程，每个进程使用了哪些资源，还需要哪些资源；对于计算机来说，它并不也不需要知道即将执行的二进制流涉及到多少分层，为什么要这么分层，对于机器来讲，它只认二进制；但是由于代码是人写的，系统是人搭建的，需要人来维护，因此，通过“分层”能够让人更好地理解程序，更好地理解系统设计，提高人与人的沟通效率，提升系统可维护性。
模式“模式”一词大家都在用，简单来讲就是我们通过实践发现的一些有价值的设计或者解决方案，这些方案能复制到类似的问题域中很好地解决问题，从而提升生产效率，他是通过实践找到的捷径。书中给出了Chirstopher Alexander给出的定义，我觉得很好：
模式描述一个不断重复发生的问题以及该问题解决方案的核心，这样我们能够使用该方案二不必做重复劳动。
所以，一个模式包含如下关键部分：问题上下文、核心解决方案。martin的书在讲后续的每个模式的时候，也据此将模式分成了几部分来介绍：模式名称、意图和概要、运行机制、使用时机、进一步阅读。
模式总结 事务脚本模式概要：事务脚本使用过程来组织业务逻辑，每个过程处理来自表现层的单个请求，可以适用于简单的业务场景，可以加快开发速度，去掉繁琐的分层。
我的思考：事务脚本并不是指现阶段很多项目中出现的“面条式”代码，而是根据简单业务场景简单处理，不引入复杂分层，一个过程走到底，对于简单/临时性的业务应用，可以快速开发/测试，省去了繁琐的框架搭建。
项目实践：实际项目中并没有遇到可以应用事务脚本的场景，通常意义上的企业应用，业务逻辑都不会太简单，也不是临时性的项目。 领域建模
模式概要：合并了行为和数据的领域对象模型，核心在于将易变的业务逻辑内聚在领域模型中。