架构整洁之道的作者是创造“Clean神话”的Bob大叔，作者总结了其数十年的软件从业经历，围绕构建整洁架构展开讨论，系统的分享了整洁架构的方方面面。
架构师要做什么。软件架构的价值可以在两方面体现，一方面是行为价值，其实就是功能性需求，另一方面是架构价值，其价值体现在非功能性需求，对于服务与系统可用性、可维护性、可测试性的追求。架构师作为软件建设的核心负责者，工作也应从行为价值与架构价值作为抓手来展开工作。架构的终极目标是“用最小的人力成本来满足构建和维护系统需求”，在架构推行的过程中，对上需要与公司做斗争，首先的出发点是创造软件价值，但是同时也需要平衡时间、金钱、团队人员投入等因素来达到最小人力成本的因素，最终一定是软件价值与投入成本平衡的产物，一味的追求软件价值也是不够成熟的表现；对内则需要与团队做斗争，研发人员潜意识会偷懒，因而会向违背架构整洁的方向走，软件系统随着时间的推移，也是逐步熵增，架构师则是系统反熵增的奋斗士，保持系统的可维护性和可测试性也就是软件架构价值的核心体现。架构的思维模型：“复杂问题简单化、简单问题标准化、标准问题自动化”，这个思维模型也比较实用。要明白一个很重要的点，架构没有银弹，解决一个问题的同时往往会带来另一个问题。架构就是要学会平衡，综合考虑编码、质量、部署、发布、运维、排障、升级全链路的软件生命周期。架构工作有两个方针：尽可能长时间地保留尽可能多的可选项，这里的可选项指无关紧要的细节设计，比如Web组件、数据库存储等，这些不当影响业务核心架构；另外是低层次解耦方式能解决的，不要用高层次解耦方式。
架构师的武器库。首先是软件架构的最终结果是一个像地图一样的图网，图网的核心在于节点与节点间网络软件，另外在架构中还增加了区域的划分——分层，做好架构其实就是要玩转这张网络。系统的每一个核心组件可以看作一个节点，节点的选择划分便是最初要做的，可以采用领域驱动的设计模式来对业务领域建模；一个麻雀虽小五脏俱全的节点必要考虑其内部层次结构，以使其职责明确，层次清晰；而节点(组件服务)间关系的构建，也会有多种方式，建立关系必发生跨边界调用，这里是耦合的高发点，需要做好合理管控，层次来看，可以是直接源码层次的方法引用，也可以通过依赖引用，还可以通过服务调用，在API层面耦合；架构网络不是杂乱无章的，而是层次清晰的，从上到下，从入到出，依赖关系是有向的箭头，控制高层次策略组件依赖底层通用实现细节组件，避免细节依赖策略；划分层次与边界是一个艺术活，当常常挂于脑中。
架构工作不同阶段的目标。设计阶段，设计阶段服务于开发阶段，在设计阶段架构需要梳理清楚开发阶段的实现技术，为开发阶段的正常推进提供保障；开发阶段，开发阶段在完成开发任务实现功能的同时，帮助开发者更加需要考虑部署阶段的易部署、无状态、监控等部署要素，也行考虑将来的维护推展，开发中应尽量采用最佳实践，避免使用骚操作，避免未进过深思熟虑详细检验的设计方案；部署阶段，文档积累，实现自动化部署；维护阶段，减少探秘成本和风险，探秘成本是对现有软件系统的挖掘工作，确定新功能或修复问题的最佳位置和方式。风险是做改动时，可能衍生出新的问题，良好的设计开发过程文档记录就是要避免后期维护时的探秘成本。
说说架构设计原则：
OCP：开闭原则，设计良好的软件应该易于扩展，同时抗拒修改。这是进行架构设计的主导原则。
SRP：单一职责原则，任何一个软件模块都应有且只有一个被修改的原因。该原则是组件拆分的基本原则。
LSP：里氏替换原则，当用同一接口的不同实现互相替换时，系统的行为应该保持不变。指导如何使用继承的方法，实现细节的可替换性，指导设计API接口。
ISP：接口隔离原则，不依赖任何不需要的方法、类或组件，在源码层次避免不需要的依赖，高层次策略性代码不应依赖实现底层细节的代码。指导接口设计。
DIP：依赖反转原则，跨越组建边界的依赖方向永远与控制流的方向相反。DIP守则：
- 在代码中应多使用抽象接口，尽量避免使用那些多变的具体实现类
- 不要在具体实现类上创建衍生类
- 不要覆盖包含具体实现的函数
- 应避免在代码中写入与任何具体实现相关的名字，或者是其他容易变动的事务的名字
REP（复用、发布等同原则）
软件复用的最小粒度应等同于其发布的最小粒度。直白地说，就是要复用一段代码就把它抽成组件。该原则指导我们组件拆分的粒度。
CCP（共同闭包原则）
为了相同目的而同时修改的类，应该放在同一个组件中。CCP 原则是 SRP 原则在组件层面的描述。该原则指导我们组件拆分的粒度。对大部分应用程序而言，可维护性的重要性远远大于可复用性，由同一个原因引起的代码修改，最好在同一个组件中，如果分散在多个组件中，那么开发、提交、部署的成本都会上升。
CRP（共同复用原则）
不要强迫一个组件依赖它不需要的东西。CRP 原则是 ISP 原则在组件层面的描述。该原则指导我们组件拆分的粒度。
无依赖环原则
健康的依赖应该是个有向无环图（DAG），互相依赖的组件，实际上组成了一个大组件，这些组件要一起发布、一起做单元测试。
稳定依赖原则
依赖必须指向更稳定的方向，更稳定意味着更低的变更成本。组件稳定性的定量化衡量指标是：不稳定性（I） = 出向依赖数量 / (入向依赖数量 + 出向依赖数量)。
稳定抽象原则
一个组件的抽象化程度应该与其稳定性保持一致。为了防止高阶架构设计和高阶策略难以修改，通常抽象出稳定的接口、抽象类为单独的组件，让具体实现的组件依赖于接口组件，这样它的稳定性就不会影响它的扩展性。组件抽象化程度的定量化描述是：抽象程度（A）= 组件中抽象类和接口的数量 / 组件中类的数量。
注意实现细节。Web是实现细节。数据库是实现细节，应当从业务逻辑出发。应用程序框架是实现细节，避免代码严重依赖框架技术。
整洁架构是架构师的至高追求，建设整洁架构伴随着软件生命周期的从始至终，首先要牢记使命与原则，在设计中加以应用，与反模式的原则做斗争。