4.1 穿越框架变化的设计原则

框架会变。设计压力不会。好的设计原则应该在语言、框架和架构潮流变化时仍然帮助你思考。

设计的目的，是让有价值的变化更便宜，让危险的变化更可见。

核心原则

关注点分离：系统中不同部分应该拥有不同的变化理由。

模块化：系统被划分成有意义边界的部分。

抽象：调用方依赖更简单的概念，而不是依赖所有细节。

信息隐藏：模块保护调用方不受内部易变决策影响。

高内聚：模块内部的东西真的属于同一件事。

低耦合：一个模块变化时，不会无谓地迫使其他模块变化。

这些不是审美口号。它们是成本控制工具。

围绕变化设计

一个实用设计问题：

什么东西可能独立变化？

例子：

• 支付服务商可能独立于结账策略变化。
• UI 文案可能独立于验证逻辑变化。
• 授权规则可能独立于路由布局变化。
• 存储表示可能独立于业务流程变化。

当可能独立变化的东西被困在一起，未来每次变化都会变危险。

过度设计陷阱

不要一开始就抽象一切。抽象有成本：间接层、命名、测试、文档和调试。

好设计在真实变化压力处找到边界。过早设计则因为“看起来专业”而发明边界。