模型的两轴分类，及软件研发的三级映射链条

模型的价值在于只呈现系统某一视角的形态、屏蔽其他视角，从而让人聚焦于当下要解决的问题——同一个复杂系统在架构师、程序员、运维人员眼里呈现完全不同的样子（子系统交互关系的组合、代码与API接口的组合、服务节点的组合），这正是不同模型服务不同职能角色的体现。模型可以从两条独立的轴来分类：一条是”是否真实存在”——物理模型代表真实存在的东西（汽车仿真模型、MVP最小产品集、一张数据库物理表），概念模型代表只存在于想象中的抽象概念（价值模型、数据ER模型，在现实或虚拟世界中都没有可见形式）；另一条是[[系统描述的三种维度：功能、结构、行为|系统描述的三个维度]]——概念模型和物理模型又都可以按功能、结构、行为进一步细分，业界流行的建模语言基本都能归入这三类（UML的用例图属于功能模型，类图/组件图/部署图属于结构模型，时序图/活动图属于行为模型）。从软件系统研发的角度看，整个过程本质上是把现实世界映射到虚拟世界，这个映射经过三级转换：先对现实世界建模，得到现实世界的物理模型；再把这个物理模型转换成计算机世界里的概念模型；最后用编程语言等工具把这个概念模型落地为软件系统的物理模型。可迁移启发：讨论”这个模型该怎么画”之前，先用这两条轴给它定位——它描述的是真实存在的东西还是抽象概念，讨论的是功能、结构还是行为——定位清楚之后，往往就能立刻判断这个模型该采用哪种表达方式、该给谁看。

结构图：

flowchart TB
  A["模型分类轴一:是否真实存在"]
  A --> A1["物理模型<br/>(如仿真模型/MVP/数据库物理表)"]
  A --> A2["概念模型<br/>(如价值模型/ER模型,无可见形式)"]
  B["模型分类轴二:系统描述维度"]
  B --> B1["功能模型(如用例图)"]
  B --> B2["结构模型(如类图/部署图)"]
  B --> B3["行为模型(如时序图/活动图)"]
  R["软件研发的三级映射"]
  R --> R1["现实世界→建模→现实世界的物理模型"]
  R1 --> R2["转换→计算机世界的概念模型"]
  R2 --> R3["落地→软件系统的物理模型"]