软件架构
引入软件架构治理复杂度，所以软件架构就是解决部分的软件复杂度的。
架构本质：是约束； 不告诉我们应该怎么做，而是教会我们不该做什么
递增的复杂度：<br>软件的复杂性不会凭空消失，并且会逐级递增
模糊性创造了复杂，依赖性传播了复杂
复杂性往往不是由单个灾难引起的
我们可以容易地说服自己，当前变更带来的一点点复杂性没什么大不了
编程思维论<br>（不可取但快）
战术编程<br>（不可取但快）
当前一定是最快的
不会花费太多时间来寻找最佳设计
每个编程任务都会引入一些复杂度
重构会减慢当前任务速度，所以保持最快速度
战略编程<br>（建议采用）
工作代码远远不够
引入不必要的复杂度不可接受<br>
不断对系统设计进行小幅改进
投资心态（每位工程师都需要对良好的设计进行连续的少量投资 10~20%）<br>
架构伪论
好的代码自解释（还是需要有注释的）
永远追求优雅
架构终极目标
架构终极目标，用最小的人力成本来满足构建和维护该系统的需求。架构始终是我们解决复杂度的一个工具，如果当前系统并不复杂，我们不需要为了所谓的优雅去过分改造与优化它，持续将成本置在一个较低水位，就是软件最好的解决办法。<br><br>业务简单的系统不应用 DDD 架构，弱交互场景也无需进行前后端分离，哪怕是邓总设计师在规划新中国的发展上，也是制定了一套‘中国特色社会主义’制度。不要盲从一些教条的观念，选择适合自己的，控制在可控制范围内，既不过度也不缺失。毕竟没有绝对的优雅，甚至没有绝对的正确。
