在SaaS产品开发中，实体设计是将抽象概念转化为具体操作对象的关键步骤。它不仅关系到产品的可用性和用户体验，还直接影响到产品的维护和扩展性。文章详细介绍了实体设计的六个步骤，旨在帮助读者更好地理解和实践实体设计。

在SaaS产品的世界里，抽象能力不仅是构建高效解决方案的基石，更是推动创新和满足用户需求的关键。我们已经探讨了如何从复杂的需求中抽象出核心问题，如何将复杂的功能抽象成简洁易用的设计，以及如何将复杂系统进行场景化架构设计。今天，我们将深入探讨一个经常被忽视但同样重要的领域：实体设计。

实体设计，在SaaS产品中，指的是将抽象的概念转化为具体、可操作的对象或模块。它不仅关乎产品的外观和感觉，更关乎产品如何在实际中运作，以及如何与用户和其他系统交互。实体设计的好坏，直接影响到产品的用户体验、性能和可维护性。

让我们开始这场实体设计的探索之旅，看看它是如何将抽象的构想转化为具体的产品价值。

它主要分为六步：

• 第一步：构建场景化产品架构：基于用户场景，抽象产品结构
• 第二步：构建关键角色流程：依据角色工作流，抽象产品流程
• 第三步：提取关键实体：从产品架构与流程中提取所有关键实体
• 第四步：关联实体关系：对不同实体，建立相应的关联关系
• 第五步：丰富实体设计：补充缺失实体，完善实体关系和属性
• 第六步：场景验证与调整：根据用户场景和需求，验证并调整实体结构的扩展性

咱们还是以HR SaaS产品为例，一步一步拆解，希望对你有所启发。

第一步：构建场景化产品架构：基于用户场景，抽象产品结构

实体设计依赖于产品架构设计，两者共同构成产品架构的完整视图。

产品架构图是静态的，为实体设计提供基础；实体设计图则是动态的，实现产品架构的具体化。有关产品架构图的详细内容，可以参考“如何将复杂系统进行场景化架构设计”一文。

第二步：构建关键角色流程：依据角色工作流，抽象产品流程

HR SaaS的关键角色是HR，其次是决策者（即CEO/HRD），再次是业务管理者（即部门/门店负责人），最后是员工。

以考勤业务为例。

我们将创建关键角色的主要流程图，重点关注考勤HR和业务管理者。

建议：为每个角色绘制独立的流程图，以便更清晰地理解其工作流程和场景。特别是对新产品伙伴，避免像我一样偷懒。

第三步：提取关键实体：从产品架构与流程中提取所有关键实体

这一步的关键是基于产品架构和用户流程图进行“按图索骥”，提取所有相关名词，确保它们相互独立且不重复。

每个实体应像工种一样，拥有独特的名称和在系统中的明确职责，理想情况下，每个实体负责一个特定的功能。

以考勤业务为例，各个模块的独立且不重复实体情况如下：

考勤管理：员工、考勤档案、考勤确认规则；

排班管理：员工、排班日历、节假日、班次时间、排班组、排班规则；

假期管理：员工、假期规则、请假记录、请假审批、假期余额；

加班管理：员工、加班规则、加班审批、加班记录；

调班管理：员工、调班规则、调班记录、调班审批；

出差/外出管理：员工、出差/外出规则、出差/外出记录、出差/外出记录；

工时管理：员工、工时规则、工时记录；

设置：考勤周期、考勤机、出勤规则、打卡规则、打卡记录、补贴规则、补贴记录、扣款规则、扣款记录；

班次设置：班次、班次组、循环模版；

报表：员工、字段、日报、月报

第四步：关联实体关系：对不同实体，建立相应的关联关系

每个实体作为一个静态名词，只有通过赋予其明确的职责和合作关系，才能发挥价值，就像职位一样，需要明确的分工和与上下级、同级的协作，以产生有效的成果。

实体关系通常分为三类：1对1、1对N、N对N。利用这三种关系，我们可以关联实体，实现它们之间。

第五步：丰富实体关系：补充缺失实体，完善实体关系和属性

实体设计的价值是在灵活性、体验性和扩展性之间进行权衡。实体的独立性、关键属性设计以及实体间的关系共同塑造了实体架构，影响其效率和适用性。

所以当你在设计实体架构图时，可通过以下四个方向进行丰富：新增子实体、拆分关键实体、完善实体关系、完善实体属性。

首先是新增子实体。

在大框架设计中，深入特定场景流程后，可能发现实体缺失，影响场景的灵活性、扩展性或体验。

比如假期管理可按类型分为年假、事假、调休等多种假期，按额度分为有余额和无余额，按计算方式分为按工作日或自然日计算。为此，可新增“假期模板”子实体，提供自定义假期。

第二是拆分关键实体。

比如加班是一个关键场景，则可将【加班规则】实体进一步拆分为：计算规则、补偿规则、限制规则、舍去规则、使用规则，每个子规则负责一个具体的功能。

或排班也是一个关键场景，则也可增加不同维度的实体。

第三是完善实体关系。

实体关系的设计对实体架构的扩展性和用户体验有直接影响。

比如出勤方案与排班规则可以设计为N对N的灵活关系，也可以是N对1的简化关系。N对N关系提供最大灵活性，允许每个出勤方案独立关联多个排班规则；而N对1关系将排班规则视为整体，牺牲灵活性以简化配置。

第四是完善实体属性。

关键属性的设计对实体架构的扩展性和用户体验，也有直接影响。

比如适用范围作为规则/方案的关键属性，决定了哪些人适用于哪些规则。可以设计每个规则有独立的适用范围以增加灵活性，或者让关键实体如出勤方案拥有适用范围，其他规则实体共享，从而简化规则的管理。

第六步：场景验证与调整：根据用户场景和需求，验证并调整实体结构的扩展性

当实体架构设计完成后，避免考虑不周全的情况，以我的经验的话，就会用目前可以想象到的所有场景来进行“验证”。

这就像是一个思想实验一样，你把整理好的（目前）所有已知场景，分别代入到你的实体设计中进行验证。

一般验证三部分：体验性、灵活性、扩展性。

第一是体验性。基于用户流程，进行完整场景式的演绎，看看在现有流程中，是否体验足够好。

比如考勤HR在配置各类规则时，我们可以有两种不同思路：

• 思路1是每个规则相互独立，相互之间无关联。比如打卡规则、出勤规则、加班规则等，都有自己不同的适用范围，互不影响；
• 思路2是每个规则组合使用，由一个中间实体（即考勤方案）进行统一管理，共享同一个适用范围。

从用户体验角度，思路2优于思路1。这类似于与客户对接时，思路2只需对接一人，而思路1则需对接多人，显然更繁琐。

第二是灵活性。确保系统能适应不同客户场景，保持用户操作自由度。

在HR考勤管理中，除了执行考勤规则，还需对分区域/部门的员工考勤数据进行纠错、归档和确认。例如，北京总部员工由张三管理，而成都、武汉、重庆等分公司员工由李四管理。每月确认出勤后，数据交给王五进行工资发放。

思路1：考勤方案兼职多能，同时负责权限划分。例如，北京总部员工使用考勤方案A，由张三管理；成都、武汉、重庆员工使用考勤方案B，由李四管理。

思路2：考勤组专职专能。考勤方案仅负责规则制定，数据管理由考勤组独立负责。例如，北京总部员工属于考勤组1，由张三管理；成都、武汉、重庆员工属于考勤组2，由李四管理。

从自由度看，思路2在自由度和效率上优于思路1，类似于职场中的专职专岗，职责明确，工作安排灵活。

第三是扩展性。如果体验性和灵活性无法兼得，需考虑当前架构设计的可扩展性，确保以最小成本进行后期扩展，避免前期成本低但后期难以扩展的方案。

排班管理是考勤的核心功能之一，不同行业/企业需求各异。例如，制造业排班可能按时间规律性交替或按任务量调整；复杂度高时，员工只需选择白班或夜班。门店连锁行业则常见小时工不固定上班时间，正式员工常支援、调店/调班。

延伸场景包括按人员排班、按任务排班、按小时排班，支援调班、调店调班等，以及自动规律性排班和指定周期内自动复杂排班。

如果当前实体关系架构，不支持快速扩展，则需考虑调整。

总结一下

本文主要分享了如何将构想转化为具体的实体架构设计，介绍了设计的六步：

第一步：构建场景化产品架构：基于用户场景，抽象产品结构。关键动作是基于用户场景绘制全景产品架构图；方法论是【以终为始，全面设计；以始为终，最小闭环】。

第二步：构建关键角色流程：依据角色工作流，抽象产品流程。关键动作是明确产品的所有服务角色，根据产品阶段确定角色优先级，并绘制关键角色流程图；

第三步：提取关键实体：从产品架构与流程中提取所有关键实体。关键动作是找出产品架构与角色流程中的所有关键名词；

第四步：关联实体关系：对不同实体，建立相应的关联关系。关键动作是把所有关键名词用三种关系（即1对1/1对多/多对对）进行关联，让它们相互实现协同；

第五步：丰富实体设计：补充缺失实体，完善实体关系和属性。关键动作是查缺补漏实体关系，该加则加，该删则删；

第六步：场景验证与调整：根据用户场景和需求，验证并调整实体结构的扩展性。关键动作是收集足够需求场景，进行逐一验证，并在体验性、灵活性与扩展性之间进行权衡取舍。