概述

《架构整洁之道》一书中有提到设计和架构的感念，它们究竟是什么？书是这么说的，它们的层次不一样，架构更“高层级”的说法，这类讨论一般都把“底层”的实现细节排除在外。而设计往往指代的具体的系统底层组织结构和实现的细节。

如果作为一名系统架构师，这两个概念是不分家的，“架构设计”。而这种思想和我不谋而合。

读感

首先明白，架构设计的目标是什么，或者说终极目标是什么？用最小的人力成本来满足构建和维护该系统的需求。这句话过于总结了，而其中给了一个比较直白的例子来说，“一个软件架构，可以通过它的维护成本来衡量，如果该成本很低，并且在系统的整个生命周期内一直能维持这样的低成本，那么这个系统的设计就是良好的。如果该系统的每次发布都会提升下一次变更的成本，那么这个设计就是不好的”。

上面提到了架构这个概念，但是软件的价值标准却不单单是这一个概念来体现的。作者认为，对于每个软件系统来讲，都可以通过行为和架构两个维度来体现它的实际价值。应该确保自己的系统在这两个维度上的实际价值都能长时间维持在很高的状态。更不能够关注错误的维度，或者忽视其中的某个维度。

行为

关于行为价值，我不是很理解书中所说的具体指代。但我所认为的，就是业务逻辑的体现，即是需求的实现。

架构

关于架构价值，作者有一个很有趣的概念，让我眼前一亮，我们如何理解software和hardware这两个词汇。而以我开发多年的经验来讲，这对我来说其实就是软件和硬件的意思。“ware”的意识是“产品”，而“soft”的意思，是指的软件的灵活性。那些对机器上很难改变的工作行为，我们通常称之为硬件（hardware）。这个理解简直打开了我的大门。让我重新审视了一个软件，哦不，是software这个含义。

但是说了这么多，还是没有提及架构价值。通过引申软件这次一词，想要表达的就是“软”，什么是软，就是应用容易被修改。当需求方改变需求的时候，软件变更必须可以很简单而方便地实现。变更实施的难度应该和变更的范畴（scope）成等比关系，而与变更的具体形状（shape）无关

它这里的范畴还是最好直接翻译成范围，范畴这个概念层次太高，过于哲学。放在这里，真的不是很懂。但是如果是变更的范围，就好懂很多了。

在具体讲讲加粗的这句话。范围我们已经懂了，变更的范围，即需求修改或是新增删除所涉及的模块、类、函数。那么形状是什么？作者给的示例是这样说的，我们常常会认为自己的工作就是把方螺丝拧到圆螺丝孔里面。而这违背了架构设计的初衷，如果设计偏向某种特定的“形状”，那么之后的变更只会越来越难。

其表示什么呢？继续以这个例子为例，如果我有一个圆螺丝孔，第一时间不应该是想着如何把方螺丝拧进去，而是如何创建一个接口，使得这个接口对外可以接收任何“形状”的螺丝，而最终和螺丝孔相接的就是圆孔。这就是我的理解。

软件人的职责

艾森豪威尔矩阵讲了一个道理，难题分为两种，紧急的和重要的，而紧急的难题永远是不重要的，重要的难题永远是不紧急的。对于这句话，我是不敢苟同的，因为作为一个软件开发者来说，经常收到紧急而又重要的任务那是太多了。

软件系统中，行为是紧急的，架构是重要的

书中将四类事情进行了排序
1、重要且紧急
2、重要不紧急
3、不重要但紧急
4、不重要且不紧急
显然作者把重要的层级拉高了。业务和开发人员常常把第三优先级提到第一优先级去做，这不是混淆，而是没有区分这两类。如何区分，评估系统架构的重要程度，这就是软件开发人员自己的职责了。

总结

目前两章的重点，以及我个人的理解就这么多了，之后文章会开始讲后面章节的我的读感已经认为重要的内容以及有趣的认识，