逻辑模型是一个核心概念，它描述系统做什么（功能与数据关系），而不涉及怎么做（具体技术实现）。它介于需求分析和物理设计之间，是理解业务、沟通需求和设计架构的桥梁。
简单说：逻辑模型回答“系统需要处理哪些信息、遵循哪些规则”，物理模型回答“用哪种数据库、部署在什么服务器上”。
一、逻辑模型的核心特征
| 特征 | 说明 |
|---|---|
| 与实现无关 | 不指定编程语言、数据库产品、操作系统或网络协议 |
| 聚焦业务逻辑 | 描述业务流程、数据实体、规则和关系 |
| 面向用户与设计者 | 用户能看懂（确认需求），设计者能据此做物理设计 |
| 抽象层次高 | 忽略性能、存储、并发等技术细节 |
二、逻辑模型的主要类型
在软件工程中，逻辑模型通常体现在以下几个层面：
1. 数据逻辑模型
描述系统中数据的结构、关系和约束，最典型的是实体-关系图（ERD）。
实体：业务对象，如“用户”“订单”“商品”
属性：实体的特征，如“用户”有“姓名”“邮箱”
关系：实体间的关联，如“一个用户可以有多个订单”
约束：业务规则，如“订单金额不能为负”
示例：电商系统中，“订单”与“商品”是多对多关系，通过“订单明细”关联。这个结构不依赖 MySQL 还是 Oracle。
2. 功能逻辑模型
描述系统应具备的功能以及功能间的数据流，常用数据流图（DFD） 或用例图。
数据流图：展示数据从输入到输出的加工过程，如“用户提交订单 → 验证库存 → 生成订单 → 通知支付”
用例图：展示参与者与系统功能的交互，如“顾客”可以“浏览商品”“下单”“支付”
3. 行为逻辑模型
描述系统的状态变化和交互时序，常用状态图和序列图。
状态图：如“订单”状态从“待支付”→“已支付”→“已发货”→“已完成”
序列图：展示对象之间按时间顺序的消息传递，如用户、订单服务、支付服务之间的调用关系
4. 业务逻辑模型
更高层的业务规则描述，如业务规则引擎中的规则、决策表或活动图。
例如：“如果用户是 VIP 且订单金额超过 500 元，则免运费”
三、逻辑模型 vs 物理模型
| 维度 | 逻辑模型 | 物理模型 |
|---|---|---|
| 关注点 | 业务需求与规则 | 技术实现与性能 |
| 数据 | 实体、属性、关系 | 表、字段、索引、分区 |
| 功能 | 数据流、用例 | 类、方法、API、微服务 |
| 独立性 | 与 DBMS、语言无关 | 绑定具体技术栈 |
| 受众 | 用户、业务分析师、架构师 | 开发人员、DBA、运维 |
| 示例 | ER 图、DFD、用例图 | 建表 SQL、类图、部署图 |
四、逻辑模型在开发流程中的位置
需求分析 → 逻辑模型 → 物理模型 → 编码实现 → 测试部署
↑ ↑ ↑
用户语言 业务语言 技术语言
需求分析：收集用户想要什么
逻辑模型：把需求整理成结构化、无歧义的业务描述
物理模型：根据逻辑模型选择技术方案并优化
编码实现：按物理模型写代码
逻辑模型是需求确认的最后一关——用户能看懂 ER 图或用例图，确认“对，这就是我要的”，避免开发到一半才发现理解偏差。
五、为什么逻辑模型重要？
沟通工具：让用户、业务方、开发者在同一张图上达成共识
减少返工：在逻辑层发现遗漏或矛盾，比在代码层修改成本低得多
技术选型自由：逻辑模型稳定，物理实现可以随技术演进替换（如从 MySQL 迁移到 MongoDB）
文档资产：为后续维护、扩展、新人培训提供业务全景
六、常见误区
把逻辑模型当物理模型：一上来就画表结构、定 API，导致业务规则被技术细节掩盖
逻辑模型过于抽象：只写“系统管理用户”，没有具体属性和规则，无法指导开发
忽略非功能需求：逻辑模型通常只覆盖功能，性能、安全、可用性需另外补充
