第一章 设计与架构究竟是什么
架构和设计这两者有区别吗？
“架构”这个词往往使用于“高层级”的讨论中，这类讨论一般都把“底层”的实现细节排除在外。而“设计”一词，往往用来指代具体的系统底层组织结构和实现的细节。但是，从一个真正的系统架构师的日常工作来看，这样的区分是根本不成立的。
底层设计细节和高层架构信息是不可分割的，它们组合在一起，共同定义了整个软件系统，缺一不可。
软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求。
一个软件架构的优劣，可以用它满足用户需求所需要的成本来衡量。如果该成本很低，并且在系统的整个生命周期内一直能维持这样的低成本，那么这个系统的设计就是优秀的。如果该系统的每次发布都会提升下一次变更的成本，那么这个设计就是不好的。
第二章 两个价值维度
对于每个软件系统，我们都可以通过行为和架构两个维度来体现它的实际价值。
软件系统的行为是其最直观的价值维度。大部分程序员认为他们的工作是且仅是：按照需求文档编写代码，并且修复任何Bug。这真是大错特错。
软件系统的架构是第二个价值维度。软件应该容易被修改，当需求方改变需求的时候，当需求方改变需求的时候，软件变更必须可以简单而方便地实现。
系统行为和系统架构，哪个价值维度更重要？系统正常工作更重要，还是系统易于修改更重要？
业务部门会认为，完成现在的功能比实现未来的灵活度更重要。但讽刺的是，如果事后业务部门提出了一项需求，而你的预估工作量大大超出他们的预期，这帮家伙通常会对你放任系统混乱到无法变更的状态而勃然大怒。
软件系统的第一个价值维度：系统行为，是紧急的，但是并不总是特别重要。
软件系统的第二个价值维度：系统架构，是重要的，但是并不总是特别紧急。
优先级的排序：1.重要且紧急；2.重要不紧急；3.不重要但紧急；4.不重要且不紧急。
业务部门与研发人员经常犯的共同错误就是将第三优先级的事情提到第一优先级去做。没有把真正紧急并且重要的功能和紧急但是不重要的功能分开。这个错误导致了重要的系统架构问题让位给了不重要的系统行为功能。
软件架构师应该更关注系统的整体结构，而不是具体的功能和系统行为的实现。软件架构师必须创建出一个可以让功能实现起来更容易、修改起来更简单、扩展起来更轻松的软件架构。