一、引言--架构、企业应用、性能、模式

1.1、统一的内容：①、最高层次的系统分解，②、系统中不轻易改变的决定
1.2、简化架构和过程，将一个大型项目简化成许多小型项目
1.3、了解有哪些候选设计方法以及候选设计方法的优劣性
1.4、性能：先运行确定是否需要进行优化，配置上的重大变化会使得性能优化失败；性能指吞吐量或响应时间
1.5、响应时间是系统完成一次外部请求所需的时间，
1.6、等待时间是获得系统任何形式响应的最小时间，即时应该做的工作并不存在；如果存在远程调用，远程调用未设置响应超时时间会变得不可控
1.7、吞吐率：给定时间内能够处理多大请求量。文件拷贝则用每秒字节量来表示。对于企业来说：吞吐率通常用每秒事务数(tps)来度量。
1.8、负载：系统当前负荷描述，可以用当前有多少用户与系统相连表示
1.9、负载敏感度：系统A在10-20用户与系统相连情况下响应0.5秒。系统B在10个用户情况下响应时间是0.2秒，20个用户情况响应时间上升到2秒。此时
系统A的负载敏感度比系统B低；系统B衰减得比系统A快。
1.10、效率：效率是性能除以资源、如果一个双CPU系统的性能是30tps, 另一个系统拥有4个同样CPU，性能是40tps,则前者效率要高于后者
1.11、系统的容量：指最大有效负载或者吞吐率
1.12、可伸缩性：度量向系统中增加资源(通常是硬件)对系统性能的影响。可伸缩系统允许增加硬件后性能有合理的提高。垂直可伸缩性：增加内存。水平伸缩性：增加服务器数目
1.13、模式：特定的解决方案。描述一个再我们周围不断重复发生的问题以及该问题解决方案核心，核心：模式干什么的，解决什么问题，如何解决问题的
1.14、模式都是不完备的，需要在自己系统中去完善

二、分层

2.1.1、网络互联：FTP在TCP上，TCP架构在IP之上，IP有架构在以太网之上
2.1.2、每一层都依托在其下层之上。上层使用下层定义的各种服务，而下层对上层一无所知。每一层都对自己的上层隐藏其下层的具体细节。
2.1.3、层次分解好处：无需知道底层具体实现细节；可以替换某层具体实现，只需要前后提供的服务相同即可
2.1.4、分层架构中最困难的问题是决定建立哪些层次以及每一层的职责是什么
2.2.1、三层架构：表现层实现用户界面，领域层实现领域逻辑，数据源层存取数据
表现层：提供服务，显示信息，处理用户请求，HTTP请求，命令行调用，批出来API。 -- 职责：向用户展示信息并把从用那里获取到的信息解释成领域层或者数据源层上的各种动作
领域层：逻辑，系统中真正的核心：也称为业务逻辑，包括数据计算、数据验证、确认调用的数据源
数据源层：与数据库，消息系统，事务管理及其他软件包通信。关注与其他系统交互
2.2.2、领域层和数据源层绝对不要依赖与表现层
2.2.3、领域逻辑要么在客户端要么在服务端

三、组织领域逻辑

3.1.1、保存领域逻辑最简单的是事务脚本，事务脚本是一个过程：从表示层获得输入、进行校验和计算处理，将数据存到数据库以及调用其他系统的操作，
然后该过程将数据返回给表示层，中间可能需要大量的计算来组织和整理返回值。
3.1.2、领域模型：不是由一个过程来控制用户某一动作的逻辑，而是由每一个对象都承担一部分相关逻辑。
3.1.3、事务脚本普遍单单个方法内完成所有的工作，底层对象只有一些表数据接口。当新增算法时，需要再脚本的判断逻辑中新增许多新的条件
3.1.4、领域模型有多个对象，每个都向前传递一部分行为给另一个对象，直至创建结果。当新增算法时，只需新增相应的策略对象即可
3.1.5、组织领域逻辑是表模块。表模块是事务脚本和领域模型的一个中间地带。与领域模型区别在于表模块有一个公共的类示例。
3.1.6、抉择：取决于领域逻辑的复杂度，一般可以使用表模块，领域逻辑比较复杂选用领域模型
3.2.1、服务层：将领域层再细分两层，服务层独立，置于底层的领域模型或表模块上。