《架构整洁之道》是创造“Clean神话”的Bob大叔在架构领域的登峰之作。本篇是架构整洁之道读书笔记的开篇。
《架构整洁之道》围绕“架构整洁”这一重要导向，系统地剖析其缘起、内涵及应用场景，涵盖软件研发完整过程及所有核心架构模式。对于每一位软件研发从业人员——无论从事的是具体编码实现、架构设计，还是软件研发管理，《架构整洁之道》都是不可或缺的。
第一章
设计与架构究竟是什么？
软件架构的终极目标：用最小的人力成本来满足构建和维护系统的需求。
软件架构优劣的衡量标准：可以用它来满足用户需求所需要的成本。
如果该成本很低，并且在系统整个生命周期内一直都能维持这样的低成本，那么这个设计就是优良的。如果该系统的每一次发布都会提升下一次变更的成本，那么这个设计就是不好的。就这么简单。
软件的架构规则是相同的。本书主要讲的是软件架构规则。
无论是编程的范式再先进，最终产生的代码都是顺序结构、分支结构 、循环结构 的组合。
设计和架构没有任何区别。底层设计细节和高层架构信息是不可分割的。它们组合在一起，共同定义了整个软件系统。
软件开发的一个核心特点：要想跑得快，先要跑得稳。
第二章
软件系统的两个价值纬度：行为价值和架构价值
行为价值：
软件系统价值的行为是其最直观的价值。程序员的工作就是让机器按照某种指定方式运转，给系统的使用者创造或提高利润。
大部分程序员认为他们的工作仅是：按照需求文档编写代码，并且修复任何bug。这是大错特错的。
架构价值：
软件系统的第二个维度体现在Software 上。”ware”的意思是产品，而”sfot”的意思是指软件的灵活性。
软件系统必须保持灵活性。软件发明的目的，就是让我们可以以一种灵活的方式改变机器的行为。软件应该容易被修改。当需求方改变需求的时候，软件的变更必须可以简单而方便的实现。变更实施的难度应该和变更的范畴（scope)成等比关系。
哪个价值更重要？
紧急/重要矩阵。
艾森豪威尔说："我有两种难题，紧急和重要的，而紧急的难题永远是不重要的，而重要的难题永远是不紧急的。"
重要且紧急 | 重要不紧急 |
|---|---|
不重要但紧急 | 不重要且不紧急 |
软件系统的第一个价值维度：系统行为，是紧急的，但是并不总是特别重要。
软件系统的第二个价值维度：系统架构，是重要的，但是并不总是特别紧急。
四类事情的优先级排序如下：
1. 重要且紧急
2. 重要不紧急
3. 不重要但紧急
4. 不重要且不紧急
软件的系统架构——哪些重要的事情占据了列表的前两位，而系统行为——那些紧急的事情只占据了第一和第三位。
业务部门和研发部门经常犯的错误就是将第三优先级的事情提到第一优先级来做。换句话说，他们没有把真正紧急并且重要的功能和紧急但不重要的功能分开。这个错误导致了重要的事情 被忽略，重要的系统架构问题让位给了不重要的系统行为功能。
但研发人员还忘了一点，那就是业务部门原本就是没有能力评估系统架构的重要性的，这本来就应该是研发人员自己的工作职责！所以平衡软件架构的重要性与功能的紧急程度这件事，是软件研发自己的职责。
为好的软件架构而持续斗争。
研发团队必须从公司的长远利益出发与其他部门抗争。这和管理团队的工作一样，甚至市场团队、销售团队、运营团队都是这样。公司的内部抗争本来就是无止境的。
有成效的软件开发团队却迎难而上，毫不掩饰地与其他系统相关方进行平等的争吵。请记住，作为一名软件开发人员，你也是相关者之一。软件系统的可维护性需要你来保护，这是你角色的一部分，也是职责中不可或缺的一部分。
软件架构师这一职责的本身就应该关注系统的整体架构，而不是具体的功能 和系统行为的实现。软件架构师必须创建出一个让功能实现起来更容易、修改起来更简单、扩展起来更轻松的架构 。
请记住，如果忽视软件架构的价值，系统将会变得越来越难以维护，终会有一天，系统将变得再也无法修改。如果系统变成了这个样子，那么说明软件开发团队没有和需求方有足够的抗争，没有完成自己应尽的职责。
前两章作者分别从软件架构的目标、软件系统架构的优劣评价标准、软件系统价值三个方面阐述。在认识软件系统架构具体的规则前，让我们先对软件架构整体上有了一定的认识。确定了软件系统架构设计是重要的一件事情。
