软件越来越复杂，维护的成本越来越高。而且这种复杂程度随着时间的推移只会越来越恶化。我们有必要引入一些外熵来抵抗这些软件的腐化。

关于抵御软件腐化，一般会从静态的软件架构标准和动态的软件研发过程上来考虑。

在静态标准上，会有分层、高内聚低耦合等。

在动态上，会有重构来保证软件的逆腐化流程。

本文，我们再提出几点在日常架构实践过程中总结出的不大一样的观点。

职责单一性

这是一个静态的架构标准。CRQS 其实有这么一点这个职责单一的意思：读和写需要分离，可以进行单独的开发和优化。

关于职责分离这点，核心的观点是：在软件开发的过程中，需要尽量降低单个功能的复杂度，每个功能都聚焦在一个有限的范围。这会有助于软件质量的提高。

在实践过程中，有点像圈复杂度的判断，如果一个功能有太多的分支能力，往往是一个不好的设计，会很容易导致软件的腐化。

正例：

• CQRS：读写分离。

• 咨询、创单、改单、关单拆分成不同的方法。

• 对于不同的模型，提供独立的 CRUD 方法。

反例

• 部分老的渠道往往会定义一个大的万能接口，在里面通过各种标志、各种字段组合来实现不同的能力。

• 在代码里面根据不同的用户权限，实现不同的处理。

• 以用户体验为名，提供万能的修改能力，导致修改不同的字段会引发复杂的分支处理逻辑。

不变性

这个在建模型领域会比较常见，叫 immutable，指的是不可被修改的模型，往往指一些值对象之类的。

在软件架构上，不可变性其实也是一个很好的质量标准。

这个不可变性包括软件架构标准和软件过程标准两个方面：

1. 在设计模型和接口的过程中，尽量让控制可变更的范围：比如模型设计，控制在状态、时间戳等字段可变更，如果金额、时限等字段要变更就用失效老对象新建新对象的方式，将变更变为替换。在设计服务的过程中，控制只有写服务可以做变更，读服务严格控制写操作。

2. 模型和接口完成设计之后，就尽量不会要再去往里面添加功能。可以做小修小补，但是不要再做大的变更。如果需要做大的变更，要们重新定义，要么做拆分。

通过第一点的架构标准，相当大程度的减少了模型和服务的复杂性，有助于对抗软件的腐化过程。

通过第二点流程标准，一定程度上脱离了大量的兼容性设计和老功能运维的泥潭，用“换”代替了“修”，可以极大的简化软件过程。

正例

• 领域建模中的 Immutable。

• 开源界比较流行的重新造轮子。

• 升级过程中隔离老版本，逐步下线。

反例

• 维护 ERP 系统的梦魇。

• 审批过程中的改单流程。

• 无限兼容老版本。

有限性

从自然规律看，没有啥永恒的东西，每一个事物都是有生命周期的。从进化论看，下一代一定会比上一代更适应环境。

所以，在软件过程上，我们需要正确的看待一个软件/功能/代码的生命周期，创建->发展->衰落->消亡是正常的自然规律。该抛弃就抛弃，该下线就下线。有价值的数据和功能可以考虑迁移。迁移成本高或价值不大也可以抛弃。

所以，有限度的重构，把下线作为终极目标。