第二十章 业务逻辑
通常将应用程序划分为业务逻辑和插件两部分。
业务实体是计算机系统中的一种对象，这种对象中包含了一系列用于操作关键数据的业务逻辑。
用例描述的是某种特定应用情景下的业务逻辑。用例更靠近系统的输入和输出。而业务实体是一个可以适用于多个应用情景的一般化概念，相对地离系统的输入和输出更远。所以用例依赖于业务实体，而业务实体并不依赖于用例。
第二十一章 尖叫的软件架构
一个良好的架构设计应该围绕着用例来展开，这样的架构设计可以在脱离框架、工具以及使用环境的情况下完整地描述用例。
良好的架构设计应该尽可能地允许用户推迟和延后决定采用什么框架、数据库、Web服务以及其他与环境相关的工具。
同时，良好的架构设计还应该让我们很容易改变这些决定。
总之，良好的架构设计应该只关注用例，并能将它们与其他的周边因素隔离。
第二十二章 整洁架构
现有的系统架构思想：六边形架构、DCI架构、BCE架构。
这些架构的设计目标：按照不同关注点对软件进行切割。这些架构都会将软件切割成不同的层，至少有一层是只包含该软件的业务逻辑的，而用户接口、系统接口则属于其他层。
按这些架构设计出来的系统，都具有以下特点：
1.独立于框架
这些系统的架构并不依赖某个功能丰富的框架之中的某个函数。框架可以被当成工具来使用，但不需要让系统来适应框架。
2.可被测试
这些系统的业务逻辑可以脱离UI、数据库、Web服务以及其他的外部元素来进行测试。
3.独立于UI
这些系统的UI变更起来很容易，不需要修改其他的系统部分。如将一个系统的UI由Web界面替换成命令行界面。
4.独立于数据库
可以轻易将这些系统使用的MySQL替换成Mongo等数据库。因为业务逻辑与数据库之间已经完成了解耦。
5.独立于任何外部机构
这些系统的业务逻辑并不需要知道任何其他外部接口的存在。
整洁架构
依赖关系规则
同心圆分别代表了软件系统中的不同层次，通常越靠近中心，其所在的软件层次就越高。
架构设计的依赖关系规则：
源码中的依赖关系必须只指向同心圆的内层，即由低层机制指向高层策略。
内层圆中的代码不应该引用外层圆中代码所声明的名字，包括函数、类、变量以及一切其他有命名的软件实体。
不应该让外层圆中发生的任何变更影响到内层圆的代码。
业务实体：
业务实体这一层中封装的是整个系统的关键业务逻辑，是该应用中最通用、最高层的业务逻辑，它们应该属于系统中最不容易受外界影响而变动的部分。
用例：
软件的用例层包含的是特定应用场景下的业务逻辑。
接口适配器：
软件的接口适配器层是一组数据转换器，负责将数据从用例和业务实体的格式，转化成外部系统（如数据库、Web）的格式。也负责将来自外部服务的数据转换成系统内用例与业务实体所需的格式。
这一层中应该包含整个GUI MVC框架。展示器、视图、控制器都应该属于接口适配器层。模型部分则应该由控制器传递给用例，再由用例传回展示器和视图。
框架与驱动程序:
包含所有的实现细节，如Web、数据库。
一个基于Web、使用数据库的Java程序
第二十三章 展示器和谦卑对象
谦卑对象模式最初的设计目的是帮助单元测试的编写者区分容易测试的行为与难以测试的行为，并将它们隔离。
例如，GUI是很难进行单元测试的。可以利用谦卑对象模式将GUI的这两种行为拆分成展示器和视图两部分。
视图部分属于难以测试的谦卑对象，这种对象的代码应该越简单越好。
数据库网关接口的实现，应该都属于谦卑对象。
在每个系统架构的边界处，都可能有谦卑对象模式。边界会自然地将系统分割成难以测试的部分和容易测试的部分。通过谦卑对象模式，可以大幅地提高整个系统的可测试性。
第二十四章 不完全边界
构建完整的架构边界是一件很耗费成本的事，所以为了过渡，需要引入不完全边界。
三种不完全地实现架构边界的简单方法。
1.将系统分割成一系列可以独立编译、独立部署的组件之后，再把它们构建成一个组件。
2.单向边界。
策略模式
3.门户模式。
