第一章：分层
分层是用来分割复杂软件系统的最常用手段之一。如：操作系统建立在设备驱动和CPU指令上；FTP建立在TCP层之上，TCP建立在IP层上，IP建立在以太网上。
把分层结构想像成蛋糕，每一层都建立在它下一层上。意味着上层使用下层的服务，但是对更底层的服务一无所知。如，第四层使用第三层定义的服务，第三层使用第二层的服务，但是第四层并不了解第二层的服务。
分层的优势：
- 可以单独了解一层的东西，而不用管其他层
- 可以替换某一层的实现
- 最小化层之间的依赖
- 为建立标准做好准备
- 一个低层可以被很多高层使用（提高复用率）
分层的劣势：
- 分层对部分东西，而不是全部东西，有一个良好的封装。有时会引起连锁的更改，如，为了在用户界面上多显示一个属性，必须更改从数据库到UI之间的所有层。
- 额外的层会降低性能
企业应用中层次的进化
很久以前是没有分层的概念的，在90年代，随着C/S架构系统的兴起，层的概念变得明显起来。客户端通常包括UI和其他程序，服务器端通常是关系数据库。如果应用程序只是简单的显示数据和简单的更新数据，前面的结构可以很好的应付，但是随着领域逻辑（业务逻辑，验证，计算以及其他）的越来越复杂，把领域逻辑直接放在UI层中的做法使得程序非常复杂并且难以开发和维护，并且导致代码重复。另一种做法是把领域逻辑放在数据库的存储过程中，但是，存储过程提供的结构化机制有限，导致了一些非常古怪的代码。
在C/S结构变普及的同时，面对对象的世界也开始茁壮成长了。面对对象社区对这个问题有一个答案：转移到三层结构。一个展示层为UI服务，领域层为领域逻辑服务，和一个数据源层。但是面对对象的浪潮并没有很好的推进三层架构的应用，因为很多系统非常简单，不原意使用复杂的三层结构。
真正的冲击来自于Web领域。似乎是非常突然的，大家都原意用浏览器来取代C/S的应用。三层结构正好可以适应Web应用中只有一个瘦客户端的现实。另外，Java在其中也起了很大的作用。
layer和tier，作者把物理上应该分开的称为tier，把物理上可以不分开的称为layer。
三个主要的层
展示层：展示层的逻辑都是关于如何和用户交互的。主要职责是向用户显示信息，获取用户命令并提交到领域层和数据源层。
领域逻辑层：也被称为业务逻辑层。需要负责这个程序需要处理的领域中真正的工作。如基于输入进行计算并保存数据，验证数据的正确性等等。
数据源层：主要的逻辑是和其他系统交互，如数据库，消息系统，事物管理系统，等等。
分层并不是完全的，有时展示层也会直接访问数据源层，虽然看上去好像破坏了分层，但是实际中确工作的更好。
一个应用中相同职责的层可能有好几个，如多个展示层，多个数据源层。
对称VS非对称：Hexagonal Architecture认为外部的任何东西都是一个接口，作者认为接口分为两种，对外提供服务的，一种是向外获取服务的。
如何分层：一个简单的程序，可以在函数级别上分层；再复杂一点，可以在类级别上分层；足够复杂后可以在包，项目级别上分层。
不管如何分层的，都必须单向的依赖，不能出现依赖环。
有时很难分清什么是领域逻辑，什么不是。作者的做法是想像加入一个不同的层，如在一个web程序中加入一个命令行的展示层，如果加入这个层时需要复制什么代码，这就意味着领域逻辑被混入了展示层。相同的，可以用一个XML文件来替换关系数据库来从数据源层中取出领域逻辑。
层都在哪里运行
最简单的是都在服务器运行，如Web应用。
如果需要Web界面很难展示，操作的UI，就需要把展示层放在客户端运行。
领域逻辑层可以完全放在客户端，也可以完全放在服务器端，也可以分开放置。
数据源层最好放在服务器端。
