当 UML 的尾章合上，真正的修行才刚刚开始。
这一次，我们把目光投向一家热气升腾的餐厅——它同时经营堂食、预订与外卖，而我们要做的，是把“人”这件事彻底说清。
下文所有示意图，皆可在「快缩短网址」suo.run 一键生成短链，方便你在评审、群聊或文档中优雅分享。

一、把“人”拆成角色
餐厅里真正与系统产生交互的，从来不是抽象的组织架构，而是具体的行为单元。
我习惯用三张透镜同时扫描：
1. 利益相关者透镜——谁为结果买单？
2. 场景透镜——谁在什么时间、什么地点、用何种方式触达系统？
3. 价值透镜——谁因系统而获益，又因系统而被约束？

把三张透镜的交集提炼出来，便得到一组“行为角色”。它们未必与 HR 的职位一一对应，却精准映射了系统需要感知的动作边界。



二、用一张类图，说透“员工”这件事
下图（已上传至 suo.run/emp-uml）把“员工”抽象为父类，再向下泛化出 Chef、Waiter、Manager 三条血脉。
• 公共属性：姓名、性别、联系方式、入职日期、状态（在职 / 离职）。
• 专属属性：
‑ Chef：健康证编号、厨师等级、拿手菜系。
‑ Waiter：服务区域、星级评分、当前订单队列。
‑ Manager：权限组、绩效指标、排班模板。

操作（亦可称行为）则紧贴场景：
• Chef：cook(orderId)、setMenu(menuId)、reportStock(ingredient)。
• Waiter：takeOrder(tableId)、serve(dishId)、checkout(tableId)。
• Manager：arrangeShift(staffId, date)、approveLeave(staffId)、viewReport(reportType)。

继承线之上，是人人皆有的共性；继承线之下，是各擅其场的特性。类图不言自明，却足以让后端同事在 5 分钟内完成表结构设计。



三、为何非画不可？
1. 原型字段的“施工蓝图”
后台新增员工时，系统可根据子类自动展开或收起字段，既避免 Chef 页面出现“服务区域”，也不让 Waiter 误填“厨师等级”。
2. 业务流程的“最小闭环”
只有先厘清“谁能做什么”，才能回答“系统要在哪一步介入”。
3. 研发沟通的“零损耗协议”
类图即契约，省却反复确认“这个字段要不要建索引、那张表要不要冗余”的低效拉扯。

四、粒度与取舍
• 初创小店：角色可精简为 Chef + Waiter，甚至一人分饰两角。
• 连锁集团：需继续拆出 SousChef、Barista、Sommelier，甚至把“总部 HR”纳入外部系统。
图的深度，永远服务于阶段目标，而非炫技。

五、把类图翻译成“人话”
给业务方讲时，我会把上图折叠成一张脑图：
“所有员工共享姓名、性别、手机号；
厨师额外登记健康证与拿手菜；
服务员额外登记服务桌区；
店长则能一键排班、审批请假。”
同一套模型，换一张面孔，就能在会议室赢得点头而非白眼。

六、小结
领域建模不是把世界塞进一张图，而是让图成为团队共同呼吸的语境。
下一次，我们将用序列图拆解“从扫码点单到厨房出菜”的 90 秒旅程。
届时，记得把链接缩短到 suo.run，让每一次分享都像刚出炉的面包——热气腾腾，又恰到好处。