Keynote 原件地址
不要让我们现在编写的代码对未来的代码产生阻碍
Bob大叔的书基本都是从最基本的写代码开始娓娓道来，一切都感觉是理所当然的。
设计原则在架构层面的应用
我们一般接触设计原则是在学习设计模式时，默认这些设计原则都是代码层面的，而Bob大叔告诉我们，不是！这些原则不仅仅适用于代码层面的，也适用于架构层面。
- 单一职责原则告诉我们任何一个软件模块都应该只对某一类行为者负责。因为不同类的行为的变化速率是不一样的，比如：一个系统的GUI与业务逻辑的变更原因、变更速率显然是不同的；而业务逻辑与依赖注入框架之间的变更原因和变更速率肯定也是不一样的。所以，这些模块之间需要有一条边界线，而SRP就是画这些边界线的依据
- 开闭原则告诉我们设计良好的软件应该易于扩展、同时抗拒修改，即我们再说的面向抽象编程。而在架构层面，即需要避免高阶组件因低阶组件被修改而受到影响
- 里氏替换原则则是保障了组件间接口实现的可替换性，当对应实现需要变更时，只需要重新部署包含相应实现的组件即可，而不需要针对实现进行特殊处理或需要修改所有依赖组件
- 接口隔离原则告诉我们不要依赖带有不需要的函数的类。在架构层面则是说任何层次的软件设计都不应该依赖不需要的东西，实际上即是减少依赖
- 依赖倒置原则告诉我们高层策略性的代码不应该依赖低层细节的代码。这个原则指导我们高阶组件不应该依赖低阶组件
整洁架构
基于设计原则Bob提出了整洁架构。整洁架构从内到外包含：
- 业务实体：整个系统的关键业务逻辑，一个业务实体既可以是一个带有方法的对象，也可以是一组数据结构和函数的集合。
- 用例：特定应用场景下的业务逻辑，封装并实现了整个系统的所有用例。这些用例引导了数据在业务实体之间的流入/流出，并指挥着业务实体利用其中的关键业务逻辑来实现用例的设计目标。
- 控制器、网关、展示器：通常是一组数据转换器
- 设备、数据库、外部接口、Web、用户界面：一般是由工具、数据库、Web框架等组成的
组件重要性由内到外逐步递减，最核心的是业务实体，这是系统间的核心区别也是系统的核心竞争力。