一、
依赖倒置原则DIP是过程式编程和OO编程的分水岭：
“大多数开发人员对设计正交系统的必要性都很熟悉。只不过他们可能会使用其他一些词来描述这个过程，例如模块化、基于组件和分层，等等。系统应该由一组相互协作的模块构成，每个模块实现的功能应独立于其他模块。有时这些模块组件被组织到不同的层次上，每一层都做了一级抽象。这种分层的实现是设计正交系统的有力途径。因为每一层只使用它下面一层提供的抽象，所以可以在不影响代码的情况下极其灵活地更改底层实现。”
二、
架构就是不断地对系统进行正交分解的过程：
“优先考虑组合，而不是继承”。如果我们用正交分解的角度来诠释这句话，它本质上是鼓励我们做乘法而不是做加法。组合是乘法，它是让我们用相互正交、完全没有相关性的模块，组合出我们要的业务场景。而继承是加法，通过叠加能力把一个模块改造成另一个模块。
三、
软件有一个永恒的主题就是变化：
一个软件产品只要在其生命周期内，都会不断发生变化。变化是一个事实，所以我们需要让软件去适应变化。我们应该在设计时尽量适应这些变化，以提高项目的稳定性和灵活性，真正实现 “拥抱变化”。开闭原则告诉我们，应尽量通过扩展软件实体的行为来应对变化，满足新的需求，而不是通过修改现有代码来完成变化，它是为软件实体的未来事件而制定的对现行开发设计进行约束的一个原则。
四、
将开闭原则上移到业务系统。业务对外只读，意味着不可变，但不变的业务生命周期是很短暂的，所以要可扩。要扩展还要不变，就倒逼着要做兼容，而兼容可能会导致现有的功能职责不单一，这又倒逼着要对现有的功能做再抽象，以适应更广的“单一职责”。
所以不改是不可能的，只是改的结果应当是让项目往更稳定去发展。然而这里面其实好难，无论是新的抽象的定义还是职责范围的扩张，这都需要有强大的分析能力和精湛的设计思维、重构手法、调优能力以及站在核心目标上的权衡来支撑。然而难亦是乐趣所在。
五、
软件设计的无比美好，但它还是要在现实世界中运行的，难免要遵守现实的约束条件：
CPU速度和网络带宽往往在很大程度上决定了系统的性能，而内存和存储空间的大小也会大幅影响代码的设计野心。
六、
做架构设计也需要既“高明”又“精明”，高明让你的架构长远，精明让你的架构可以落地：
办事以“明”字为第一要义。明有两种，一种叫高明，一种叫精明。同一个地方，只有登上高山的人才看得遥远，只有登上城墙的人才觉得空旷，这就是高明。同一件东西，凭空估计不如用秤称的准确，用眼打量不如用尺量的准确，这就是精明。古之成大事者，规模远大与综理密微二者缺一不可。软件亦然。
参考资料：
《程序员修炼之道》
《架构整洁之道》
https://time.geekbang.org/column/article/167844
https://time.geekbang.org/column/article/175236
----END----
这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。