软件设计底层原则

• S：在学习和实践“软件设计底层原则”时，需要建立统一的概念和问题边界。
• C：相关概念、实现机制和工程取舍容易混在一起，导致只记住结论而无法判断适用条件。
• Q：“软件设计底层原则”要解决什么问题？它的核心抽象、工作机制和边界分别是什么？
• A：本文围绕“软件设计底层原则”整理核心概念、关键机制和工程实践，并明确其适用边界。

S 场景：当系统开始变大，讨论就会反复落到"模块怎么拆、关系怎么管、变化怎么扛"这些基础问题上。

C 冲突：局部实现总想追求快速完成，但系统整体又要求低耦合、可替换、可扩展、可维护，两者天然拉扯。

Q 问题：抛开语言、框架和具体模式，软件设计反复依赖的底层原则到底是什么？

A 回答：可以压缩为 6 个高频原则：职责、封装、组合、依赖、约束、演化。

软件工程里大量方法论，本质上都在反复处理这 6 件事：

• 职责：先切问题边界，明确一个东西该负责什么，不该负责什么。
• 封装：隔离复杂性，对外暴露稳定接口，对内隐藏实现细节。
• 组合：关注多个部分如何协作，而不是把所有能力堆进单点。
• 依赖：治理协作关系，控制耦合的方向、范围与传播。
• 约束：限制系统行为，固定边界、规则与不变量，避免失控扩散。

  Design = move invariants from human memory into structure.

• 演化：让结构能承受变化，在新增需求下仍可调整而不整体失稳。

可把它们理解为三个层次：

• 单体内部：职责、封装。
• 多体协作：组合、依赖、约束。
• 面向未来：演化。