管理系统为什么先分实体类与交付类：一种分而治之的定性方法

分而治之是应对复杂系统的通用方法：先分类，再定义，最后分别公式化。本文以实体管理类与交付管理类为例，说明这一定性方法如何决定系统的设计路径。

管理系统为什么先分实体类与交付类：一种分而治之的定性方法

为什么一上来就要分类

研究任何一个事物，第一步都是分类、起名、下定义，然后分别公式化处理。这是人类对付复杂世界的一贯套路：分而治之，各个击破。

• 第一步，先分类——把一个庞大的东西，切成两块看得懂的；
• 第二步，给每一块起个名字、下个定义——边界在哪要说清楚；
• 第三步，也是最关键的，对每一类分别做公式化处理——每一类给一套固定解法，照着套就行。

不同类型的事物，用不同的公式去解决。分错了类，后面再努力，都是南辕北辙。

两条路

一个应用系统，从业务的角度看，到底围绕什么在管？答案只有两条：

• 第一种：围绕一个事物在管——车、人、资产、学生这类东西。这一类叫实体管理类；
• 第二种：围绕一件要交付的事在管——订单、工程、检测任务这类事。这一类叫交付管理类。

两个定义

实体管理系统：围绕一个实体来完成管理活动，管理活动发生在这一条记录上。比如人力资源、固定资产、车辆管理、学生管理。它以实体台账为管理入口，在这个实体上发生的所有业务，都记在这个实体的主键上。

交付管理系统：围绕一个要交付完成的、具有重复的、固定工作模式的活动行为。比如工程管理、订单管理、飞机维修、LIMS、MES。它的管理活动围绕一条交付主流程来完成，流程的各个节点，就是这次交付的不同阶段，也叫里程碑。

一句话记住：实体类围绕"一个东西"转，交付类围绕"一件事从头到尾"转。

六维对比表

两种形状

实体类是一个点向外辐射：中间是实体台账记录，核心字段就三个——编号、名称、实体状态；四周围着的是围绕它发生的各种业务：维修保养、调度派车、保险年检、折旧报废、状态变更。无论发生什么业务，全都记在这条记录的主键上。以车辆管理为例，车还是那辆车，围绕它发生的事，一件一件往后记。

交付类是一条线从头到尾：立项 → 设计 → 施工 → 试运行验收 → 结项，这条流程上的每一个节点，都是这次交付的一个里程碑。简单的交付活动一条流程走完就结束；可以分解执行的，把一个里程碑展开成多条子流程，也就是父子流程。

混合系统怎么办：先分域

现实里绝大多数系统都是混合的。别急着选边站，先做一件事：分域。

• 左边一块实体域，放长期存在的东西：设备台账、客户档案、员工档案，以实体主键为主键，状态缓慢变化；
• 右边一块交付域，放有始有终的事：维修工单、销售订单、检测任务，以单据编号为主键，走完即归档。

中间用一根线连起来：单据引用实体主键。这是两个域之间唯一的连接点。先分域，再分别套用两套设计套路。

三问判别法

三十秒定性用的工具：

1. **你管的中心是什么？**一个东西——车、人、资产，是实体类；一件事——订单、工程、检测，是交付类。
2. **它有明确的终点吗？**长期存在、业务反复发生，是实体类；走完就结束、交完就归档，是交付类。
3. **主表的关键字段是什么？**编号 + 名称 + 实体状态，是实体类；单据编号 + 流程状态 + 里程碑，是交付类。

三个问题问完，答案基本就出来了。如果三个答案不一致——说明这是一个混合系统，回去做分域。

小结

带走三句话：

1. 系统只有两大类：围绕一个东西管的是实体类，围绕一件事管的是交付类。
2. 看字段就能分辨：编号 + 实体状态是实体，单据编号 + 流程状态 + 里程碑是交付。
3. 遇到混合系统先分域，两域之间靠单据引用实体主键这一根线连起来。

分类是为了公式化。分对了类，后面的设计就是照着套。