接着上一次的《架构整洁之道》阅读笔记01继续写：
7.软件系统的价值
软件系统可以通过行为和架构两个维度来实现实际价值
7.1行为价值
包括需求的实现，以及可用性保障（性能、稳定性），是最直观的价值
7.2架构价值
软件系统必须灵活，必须容易被修改
7.3架构价值是否是必须要有的？
如果业务是明确的、稳定的，架构的价值就可以忽略不计；但业务通常是不明确的、飞速发展的，这时架构就无比重要
7.4哪个价值维度更重要
第一个价值维度：系统行为，是紧急的，但是并不总是特别重要；第二个价值维度，系统架构，是重要的，但是并不总是特别紧急
如果忽视软件架构的价值，系统将会原来越难以维护，终有一天，系统将会变得再也无法修改，导致：重构！
7.5只关注行为价值带来的问题
当我们只关注行为价值，不关注架构价值时，会发生什么事情？这是书中记录的一个真实案例，随着版本迭代，工程师团队的规模持续增长，但总代码行数却趋于稳定
相对应的，每行代码的变更成本升高、工程师的生产效率降低。从老板的视角，就是公司的成本增长迅猛，如果营收跟不上就要开始赔钱。
7.6如何处理好行为价值和架构价值的关系
重要紧急矩阵中，做事的顺序是这样的：1.重要且紧急 > 2.重要不紧急 > 3.不重要但紧急 > 4.不重要且不紧急。实现行为价值的需求通常是PD提出的，都比较紧急，
并不总是特别重要；架构价值的工作内容，通常是开发同学提出的，都很重要但基本不是很紧急，短期内不做也死不了。所以行为价值的事情落在1和3（重要且紧急
不重要但紧急），而架构价值落在2（重要不紧急）。我们开发同学，在低头敲代码之前，一定要把杂糅在一起的1和3分开，把我们架构工作插进去。
8.软件建构是什么
规划如何将系统切分成组件，并安排好组件之间的排列关系，以及组件之间互相通信的方式
9.划分边界
架构师追求的目标是最大限度地降低构建和维护一个系统所需的人力资源。
最消耗人力资源的是系统中存在的耦合：1、过早做出的、不成熟的决策所导致的耦合；2、是那些与系统的业务需求无关的决策，包括要采用的框架、数据库、Web
器、工具库、依赖注入等。
解决方案：通过划清边界，可以推迟和延后一些细节性的决策，最终会为我们节省大量的时间、避免大量的问题。