系统理论
- S：在学习和实践
系统理论时，需要建立统一的概念和问题边界。 - C：相关概念、实现机制和工程取舍容易混在一起，导致只记住结论而无法判断适用条件。
- Q：
系统理论要解决什么问题？它的核心抽象、工作机制和边界分别是什么？ - A：本文围绕
系统理论整理核心概念、关键机制和工程实践，并明确其适用边界。
本文是 Programming as Theory Building 的主题延伸，聚焦论文思想在系统设计与工程实践中的推广；论文本身的读后笔记见该 PAPER 笔记。
工程实践用于帮助团队成员理解这个系统的理论：
| 实践 | 真正作用 |
|---|---|
| Clean Code | 让局部意图更容易被读懂 |
| 架构设计 | 让整体结构和变化方向可理解 |
| 文档 | 补充代码无法表达的背景和取舍 |
| 测试 | 固化系统行为和关键约束 |
| DDD | 用领域模型表达业务理论 |
| 设计模式 | 用共享词汇表达设计意图 |
| 图表 | 帮助建立系统心智模型 |
任何工程实践，如果不能帮助团队共享系统理论，它就会变成形式主义。
复杂度真正伤害团队的方式，是让系统的 theory 无法被完整持有、传递和更新。所以复杂度必须被解释和传承。
DDD的本质就是让业务理论和代码理论尽可能一致。
不通的系统设计范式，也是一种理论（各范式的展开与速查见 系统设计范式速查）：
| 范式 | 背后的 theory |
|---|---|
| 数据密集系统 | 数据如何成为事实源，如何被复制、索引、派生 |
| 派生数据系统 | 原始数据和视图之间如何同步 |
| 异步处理系统 | 时间、失败、重试、顺序、幂等如何处理 |
| 即时通讯系统 | 在线状态、消息投递、顺序、一致性如何定义 |
| 检索系统 | 查询意图如何映射到索引结构 |
| 一致性系统 | 外部观察到的行为和内部状态如何对齐 |
| 分层架构 | 变化和职责如何隔离 |
| 云原生架构 | 故障、弹性、调度、声明式状态如何协作 |
评价工程实践：有没有帮助团队更好地构建、表达、验证和传递系统理论？
- 好文档：设计原因、约束、替代方案
- 好测试：承诺的行为、边界、系统不变量
- 好架构：正确心智模型、关键概念显化
- 好代码：能把意图、边界、不变量、约束表达出来
总结：软件维护的本质，不是维护代码，而是维护团队对系统的理解。代码只是 theory 的外化结果。 好软件不是只有好代码，而是有一套可被团队持续理解和演进的系统理论。 代码、测试、文档、架构、DDD、设计模式，本质上都是帮助我们表达和传递这个理论的工具。
评论