软件设计心智模型

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

软件设计的核心，是把业务问题建模为稳定概念，用机制承载变化空间，用策略表达业务选择，让代码保留业务语义，并通过接口定义业务世界可以发生的动作。

建模定义概念，机制吸收变化，策略表达选择，代码承载业务，接口塑造行为。

1. 建模：把问题转化为清晰概念

软件设计首先是识别业务世界中对当前系统有用的概念，并划定它们的边界。建模不是复刻现实，而是抽取足够稳定、足够有用的业务抽象。

• 系统关心哪些对象、关系和状态？
• 哪些概念应成为核心抽象？
• 哪些细节只是当前实现？

2. 机制与策略分离：用机制承载变化，用策略表达选择

机制是系统提供的通用能力，策略是在特定场景下采用的业务规则。机制提供可能性，策略表达业务选择；机制应稳定，策略应允许替换和组合。

• 机制回答“系统能做什么”。
• 策略回答“这次业务应该怎么做”。
• 变化优先落在策略层。

3. 代码承载业务：让实现保留业务语义

代码不只是执行指令，也是在保存业务知识。如果业务概念只存在于文档、注释或人的脑子里，而代码里只剩流程和条件判断，系统会逐渐失去可理解性。

• 当前业务对象是什么；
• 当前业务状态是什么；
• 当前业务规则是什么；
• 当前动作为什么被允许或拒绝。

实现即思考

实现不是把既定设计机械地翻译成代码，而是在编码过程中不断发现并明确：

• Invariant：系统必须始终保持的规则
• Ownership：谁负责维护状态和行为
• Failure boundary：失败在哪里被捕获、隔离和处理
• Trade-off：不同方案之间的成本与收益

代码既是最终产物，也是用来暴露问题、澄清边界和验证设计的思考工具。

4. 接口塑造行为：定义系统允许世界如何变化

接口不只是技术边界，也是业务边界。它定义调用方可以请求什么、系统承诺什么，以及业务世界允许如何变化。好的接口暴露业务动作，而不是随意的数据操作。

• 暴露的是业务动作，还是底层数据操作？
• 调用方是否能绕过业务约束？
• 接口是否表达了系统真正承诺的语义？

Library API：表达调用者意图，而不是暴露实现

好的 Library API 应该优先表达调用者的意图，而不是暴露库内部的实现细节。设计时应不断追问：调用者真正想完成什么？

• Bad API：暴露实现词汇，调用者必须理解内部机制。
• Good API：暴露问题领域词汇，调用者可以直接表达目标。

好的 API 让调用者表达意图，而不是理解实现。

好的 API 不应把实现细节、资源生命周期和状态约束交给调用者思考，而应在结构中提前封装这些复杂性。

API 隐藏的每一个不必要决策，都是调用者少维护的一个不变量。

最终目标是：让正确用法自然，让错误状态难以产生。

好设计的四个特征

1. 意图清晰，机制隐退：调用者能直接看到要完成什么，而不必理解内部如何实现。
2. 不变量被局部化：每个模块自行维护自己的约束，避免把规则扩散给调用者。不变量定义什么是合法状态。
3. 非法状态难以表达：非法状态就是违反不变量的状态；通过 API 和数据结构设计，让这类错误状态无法轻易构造。
4. 支持局部推理：理解或修改一个模块时，不需要同时掌握整个系统。

设计思路

从问题出发，提炼调用者意图；围绕意图设计不变量，再选择实现方式。

问题 → 意图 → 不变量 → 实现