谁开，谁闭？

1 永远逃避不了的硬件，软件，固件

《代码整洁之道》一书里，有一个非常形象的描述：

硬件（Hardware）：指创造了之后不可（或者很难）变更的东西。

数据库对于开发来说，就属于”硬件“，数据库选型后基本上后面不会再变，

比如：用了MySQL就很难再改为MongoDB，改造成本过高。

软件（Software）：指创造了之后可以随时修改的东西。

对于开发来说，业务代码应该追求做”软件“，因为业务流程、规则在

不停的变化，我们的代码也应该能随时变化。

固件（Firmware）：即那些强烈依赖了硬件的软件。

我们常见的是路由器里的固件或安卓的固件等等。

固件的特点是对硬件做了抽象，但仅能适配某款硬件，不能通用。

所以今天不存在所谓的通用安卓固件，而是每个手机都需要有自己的固件。

数据库在本质上属于”硬件“，DAO（Data Access Object） 在本质上属于”固件“，而我们自己的代码希望是属于”软件“。

但是，固件有个非常不好的特性，那就是会传播，也就是说当一个软件强依赖了固件时，由于固件的限制，会导致软件也变得难以变更，最终让软件变得跟固件一样难以变更。

这时就需要一个模式，能够隔离我们的软件（业务逻辑）和固件/硬件（DAO、DB），让我们的软件变得更加健壮，而这个就是DDD中Repository的核心价值。

CPU指令是稳定的，指令序列千百万化。计算是稳定的，但数据交换是多变的。通过缺页中断，CPU将自身与多变的外部存储解耦。

例子太多太多......

---

2 业务是软件的根源，我们再将开闭原则上升到业务系统。

不变的业务生命周期是非常短暂的，所以要扩展；

要扩展还要不变，就倒逼着做兼容，而兼容又可能会导致现有的职责功能不单一，

又倒逼着对现有的功能再抽象，以适应更广的“单一职责”。

系统对外提供能力的三种形式：

1. 接口

2. 回调

3. 插件

业务在变，系统不变是不可能的。

无论是更广的单一职责还是抽象定义，只是改的结果应当是让系统往更稳定的方向。

不断下沉为核心子系统与周边子系统，交互方式就是接口，回调，插件。

业务时刻在变，在更新和淘汰。

业务是只读的，就像软件的版本号，旧的版本已尘封，代表旧的业务已落暮。

作为架构师，架构哲学是我们判断对与错的法则，但远不足以支撑做好架构。更需要做好业务需求分析，做好模块边界定义和正交分解。而无状态化是最高级的闭，只读是最好的开。