前记
为什么是再读？因为在这之前笔者已经阅读过一遍架构之道这本书，但当时缺乏项目的锻炼和试错，总觉得读的不深，终于有幸在工作期间接触到了一些项目和需求，更幸运的是项目组在开发时采用的架构正好是整洁架构，详细的说，是事件驱动开发DDD+整洁架构，关于DDD的详细内容将会在之后讨论，笔者就重新阅读了这本书📚，收获颇丰，因此这一个系列，我准备用自己的拙见描述一下整洁架构，更准确的说，应该是是读书笔记，以兹同仁。
这本书的详细地址为：架构整洁之道-罗伯特 C. 马丁-微信读书 (qq.com)
本系列会以图书的章节组织作为思路，跟随作者的脚步逐渐深入，同时，由于是再读，所以不可避免的也会穿插一些图书中其他部分的内容，所以，如果你在阅读时发现了一些难于理解或者没听说过的内容，那它大概率是在之后章节中的内容。
让我们开始吧。
设计与架构的含义
设计与架构，本质上并没有区别，底层设计细节和顶层架构信息共同定义了软件系统。
软件架构的终极目标是用最小的人力成本来满足构建和维护系统的需求，因此成本可以评估一个软件架构设计的优劣。
没有经过设计、匆匆构建的系统可能成为乱麻系统，乱麻系统在构建过程中被长期忽视代码质量和设计结构优化。认真设计软件架构可以在一定程度上避免系统成为乱麻系统，从而降低成本。
软件开发具有两个核心特点：
- 要想跑得快，要先跑得稳；
- 过度自信只会使得重构设计陷入和原项目一样的困局。
两个价值维度
软件系统包含两种价值：
- 行为价值：让机器按照某种指定方式运转，给系统的使用者创造或者提高利润；
- 架构价值：软件要够灵活，更改软件的成本要做到与需求的范畴相关，与形状无关。
怎么理解需求的范畴与形状？ 笔者自己理解范畴即需求大致的范围和所属领域，而形状指需求的细节内容。
那么哪个价值维度更重要呢？ 作者认为架构价值比行为价值更重要，因为：
- 如果某程序可以正常工作，但是无法修改，那么当需求变更的时候它就不再能够正常工作了，我们也无法通过修改让它能继续正常工作。因此，这个程序的价值将成为0；
- 如果某程序目前无法正常工作，但是我们可以很容易地修改它，那么将它改好，并且随着需求变化不停地修改它，都应该是很容易的事。因此，这个程序会持续产生价值。
业务部门与研发部门经常犯的共同错误是没有把真正紧急并且重要的功能和紧急但是不重要的功能分开，结果就是重要的系统架构问题让位给了不重要的系统行为功能。
平衡系统架构的重要性与功能的紧急程度这件事，是软件研发人员自己的职责。
笔者注：同时，即便同样是研发人员，不同的小组也会存在类似问题，正如某些前端部门认为后台只需要提供一系列接口很容易，而不知道良好设计的重要性。
为好的软件架构持续斗争✊
如果忽视软件架构的价值，系统将会变得越来越难以维护，终会有一天，系统将会变得再也无法修改。如果系统变成了这个样子，那么说明软件开发团队没有和需求方做足够的抗争，没有完成自己应尽的职责。