很好的一本书，看了前两章。大多数内容都能理解，只是有两个概念 领域模型和表模块无法做清晰的区分
。
个人感觉这本书值得读上几遍， 对于有几年开发经验的人来说，读这本书确实是一次理论的升华。
下面是前两章的读书笔记：
企业应用架构模式
引言
1)构架
最高层次的系统分解
系统中不易改变的决定
层次
大多数企业应用都是按照某种形式的层次分层设计的
2)企业应用
一般都涉及到持久化数据
一般都涉及到大量数据
一般都涉及到很多人同时访问数据
一般都涉及到大量操作数据的用户界面屏幕
问题
a)企业应用很少独立存在，通常需要与散布在企业周围的其他企业应用相集成。
b)可能存在概念不一致问题。
c)复杂的业务逻辑使开发相当困难，尽量将业务逻辑组织成有效的方式。
d）企业应用不一定是“大型系统”
3)企业应用的种类
4）关于性能的考虑
5）模式
模式的核心就是特定的解决方案。
第一部分 表述（1-8章）
第一章 分层
透明性
1）上层使用下层定义的各种服务，下层对上层一无所知；
2）每一层对自己的上层隐藏其下层的细节；
层次并不能封装所有东西，有时会带来级联修改。
过多的层次会影响性能。
分层最困难的问题是：决定建立那些层以及每一层的职责是什么。
1.1企业应用中层次的演化
客户/服务端方式 à 面向对象/三层
1.2三个基本层次
| 层次 | 职责 |
| 表现层 | 提供服务、显示信息 |
| 领域层（业务逻辑） | 逻辑、系统中真正的核心 |
| 数据源层 | 与数据库、消息系统、事务管理器及其他软件包通信 |
普遍原则
领域层和数据源层绝对不要依赖于表现层；
区分领域逻辑（最困难）
什么是领域逻辑，什么是其他逻辑？
测试办法：假象向系统中增加一个完全不同的新层，例如为WEB应用增加一个命令行界面层。如果在这个过程中，发现需要重复实现某些功能，则说明可能有一些本应该在领域层实现的逻辑，现在在表现层实现了。类似地，可以将后台数据库更换为XML文件格式，看看情况又会如何？
1.3为各层选择运行环境
1）最简单的是将所有东西部署在服务器上。客户端使用web浏览器。
好处：容易维护，无需考虑分发到不同客户端并维护与服务器同步等问题，也不用考虑客户机上与其他软件的兼容性。
缺点：客户响应时，需要来回的通信开销。
2）在客户机上运行应用程序
好处：系统响应好，或者在断网情况下也能正常工作。
各层
数据源层：一般部署在服务器端，例外情况是当需要断接操作时，可以将服务器的 功能复制到客户机上，在离线的客户机上对数据源的任何修改，都需要同步到服务器。
表现层：取决于用户界面种类。
胖客户端：表现层运行在客户端。
web界面：表现层运行在服务器端。
领域逻辑层：
可以全都运行于服务器端、可以全都运行于客户端、可以一分为二。
全运行于服务器端有助于系统维护，向客户端转移是为了响应时间和断接情况。
第二章 组织领域逻辑
领域逻辑的组织三种主要模式：事务脚本、领域模型和表模块。
事务脚本：最简单的模式，从表现层获得输入，进行简单校验和计算处理，将数据存储到数据库中。
该过程将更多的数据返回给表现层，中间进行大量的计算来组织和整理返回值。
基本的组织方式是让每个过程对应用户可能做的一个动作。所以，我们可以将这一模式想象层一个动作或业务事务的脚本。
优点：
大多数开发者都能理解的简单过程模型。
能够与一个使用行数据入口或表数据入口的简单数据源层很好的协作。
设定事务边界的方法显而易见：一个事务始于其脚本的打开，终于其脚本的关闭。
缺点：
随着领域逻辑的复杂而变的更加复杂。
大量的代码重用。
当多人同时开发的时候，程序会变得没有头绪。
可以使用领域模型来解决上面的问题。
领域模型：
用领域模型而不是事务脚本正是面向对象所极力鼓吹的“理论体系转换”的精髓。
在领域模型中，不再是由一个过程来控制用户某一动作的逻辑，而是每一个对象都承担一部分相关逻辑。
表模块：
领域模型和表模块的区别：领域模型对数据库中每一个合同都有一个相应合同的类的实例。而表模块只有一个公共的和同类实例。
2.1抉择
三种模式的抉择与 领域模型的复杂度相关。
2.2 服务层
通常将领域层细分为两层，服务层独立出来，置于底层领域模型或表模块之上。
服务层行为
服务层中行为的多少很重要。
最小情况：服务层只是一个外观，所有实际的行为都在下层对象中。服务层所做的只是将上层调用传递到更低层。
最大情况：将大多数业务逻辑都以事务脚本的形式置于服务层中。下层的领域对象变的极为简单。如果下层是领域模型，则其中的对象与数据库一一对应。
折中情况：控制器—实体风格
要点：将单个事务或用例所特有的逻辑置于事务脚本中，被称为控制器或服务。
可以讨论
1)作者建议使用最小化服务层？
2)掌控折中情况的困难度？