实体设计：如何将复杂系统进行抽象架构设计？
在SaaS产品的世界里，抽象能力不仅是构建高效解决方案的基石，更是推动创新和满足用户需求的关键。我们已经探讨了如何从复杂的需求中抽象出核心问题，如何将复杂的功能抽象成简洁易用的设计，以及如何将复杂系统进行场景化架构设计。今天，我们将深入探讨一个经常被忽视但同样重要的领域：实体设计。
实体设计，在SaaS产品中，指的是将抽象的概念转化为具体、可操作的对象或模块。它不仅关乎产品的外观和感觉，更关乎产品如何在实际中运作，以及如何与用户和其他系统交互。实体设计的好坏，直接影响到产品的用户体验、性能和可维护性。
让我们开始这场实体设计的探索之旅，看看它是如何将抽象的构想转化为具体的产品价值。
它主要分为六步：
- 第一步：构建场景化产品架构：基于用户场景，抽象产品结构
- 第二步：构建关键角色流程：依据角色工作流，抽象产品流程
- 第三步：提取关键实体：从产品架构与流程中提取所有关键实体
- 第四步：关联实体关系：对不同实体，建立相应的关联关系
- 第五步：丰富实体设计：补充缺失实体，完善实体关系和属性
- 第六步：场景验证与调整：根据用户场景和需求，验证并调整实体结构的扩展性
咱们还是以HR SaaS产品为例，一步一步拆解，希望对你有所启发。
第一步：构建场景化产品架构：基于用户场景，抽象产品结构
实体设计依赖于产品架构设计，两者共同构成产品架构的完整视图。
产品架构图是静态的，为实体设计提供基础；实体设计图则是动态的，实现产品架构的具体化。有关产品架构图的详细内容，可以参考“如何将复杂系统进行场景化架构设计”一文。
第一步：梳理产品架构-2024_08_18.png
第二步：构建关键角色流程：依据角色工作流，抽象产品流程
HR SaaS的关键角色是HR，其次是决策者（即CEO/HRD），再次是业务管理者（即部门/门店负责人），最后是员工。
以考勤业务为例。
我们将创建关键角色的主要流程图，重点关注考勤HR和业务管理者。
第二步：构建关键角色流程-2024_08_08.png
建议：为每个角色绘制独立的流程图，以便更清晰地理解其工作流程和场景。特别是对新产品伙伴，避免像我一样偷懒。
第三步：提取关键实体：从产品架构与流程中提取所有关键实体
这一步的关键是基于产品架构和用户流程图进行“按图索骥”，提取所有相关名词，确保它们相互独立且不重复。
每个实体应像工种一样，拥有独特的名称和在系统中的明确职责，理想情况下，每个实体负责一个特定的功能。
以考勤业务为例，各个模块的独立且不重复实体情况如下：
- 考勤管理：员工、考勤档案、考勤确认规则；
- 排班管理：员工、排班日历、节假日、班次时间、排班组、排班规则；
- 假期管理：员工、假期规则、请假记录、请假审批、假期余额；
- 加班管理：员工、加班规则、加班审批、加班记录；
- 调班管理：员工、调班规则、调班记录、调班审批；
- 出差/外出管理：员工、出差/外出规则、出差/外出记录、出差/外出记录；
- 工时管理：员工、工时规则、工时记录；
- 设置：考勤周期、考勤机、出勤规则、打卡规则、打卡记录、补贴规则、补贴记录、扣款规则、扣款记录；
- 班次设置：班次、班次组、循环模版；
- 报表：员工、字段、日报、月报
第三步：提取实体-2024.08.27.jpg
第四步：关联实体关系：对不同实体，建立相应的关联关系
每个实体作为一个静态名词，只有通过赋予其明确的职责和合作关系，才能发挥价值，就像职位一样，需要明确的分工和与上下级、同级的协作，以产生有效的成果。
实体关系通常分为三类：1对1、1对N、N对N。利用这三种关系，我们可以关联实体，实现它们之间的协同。
第四步：关联实体关系-ihrsaas-_-2024_08_27.png
第五步：丰富实体关系：补充缺失实体，完善实体关系和属性
第五步：丰富实体关系-ihrsaas-2024_08_27__1_.png
实体设计的价值是在灵活性、体验性和扩展性之间进行权衡。实体的独立性、关键属性设计以及实体间的关系共同塑造了实体架构，影响其效率和适用性。
所以当你在设计实体架构图时，可通过以下四个方向进行丰富：新增子实体、拆分关键实体、完善实体关系、完善实体属性。
首先是新增子实体。
在大框架设计中，深入特定场景流程后，可能发现实体缺失，影响场景的灵活性、扩展性或体验。
比如假期管理可按类型分为年假、事假、调休等多种假期，按额度分为有余额和无余额，按计算方式分为按工作日或自然日计算。为此，可新增“假期模板”子实体，提供自定义假期。
第二是拆分关键实体。
比如加班是一个关键场景，则可将【加班规则】实体进一步拆分为：计算规则、补偿规则、限制规则、舍去规则、使用规则，每个子规则负责一个具体的功能。
或排班也是一个关键场景，则也可增加不同维度的实体。
第三是完善实体关系。
实体关系的设计对实体架构的扩展性和用户体验有直接影响。
比如出勤方案与排班规则可以设计为N对N的灵活关系，也可以是N对1的简化关系。N对N关系提供最大灵活性，允许每个出勤方案独立关联多个排班规则；而N对1关系将排班规则视为整体，牺牲灵活性以简化配置。
相关案例与示意图，可见：功能设计2：如何将复杂的功能抽象成简洁易用的设计？
第四是完善实体属性。
关键属性的设计对实体架构的扩展性和用户体验，也有直接影响。
比如适用范围作为规则/方案的关键属性，决定了哪些人适用于哪些规则。可以设计每个规则有独立的适用范围以增加灵活性，或者让关键实体如出勤方案拥有适用范围，其他规则实体共享，从而简化规则的管理。
相关案例与示意图，可见：KISS原则：SaaS产品设计最重要的原则（上）
第六步：场景验证与调整：根据用户场景和需求，验证并调整实体结构的扩展性
当实体架构设计完成后，避免考虑不周全的情况，以我的经验的话，就会用目前可以想象到的所有场景来进行“验证”。
这就像是一个思想实验一样，你把整理好的（目前）所有已知场景，分别代入到你的实体设计中进行验证。
一般验证三部分：体验性、灵活性、扩展性。
第一是体验性。基于用户流程，进行完整场景式的演绎，看看在现有流程中，是否体验足够好。
比如考勤HR在配置各类规则时，我们可以有两种不同思路：
- 思路1是每个规则相互独立，相互之间无关联。比如打卡规则、出勤规则、加班规则等，都有自己不同的适用范围，互不影响；
- 思路2是每个规则组合使用，由一个中间实体（即考勤方案）进行统一管理，共享同一个适用范围。
从用户体验角度，思路2优于思路1。这类似于与客户对接时，思路2只需对接一人，而思路1则需对接多人，显然更繁琐。
第二是灵活性。确保系统能适应不同客户场景，保持用户操作自由度。
在HR考勤管理中，除了执行考勤规则，还需对分区域/部门的员工考勤数据进行纠错、归档和确认。例如，北京总部员工由张三管理，而成都、武汉、重庆等分公司员工由李四管理。每月确认出勤后，数据交给王五进行工资发放。
- 思路1：考勤方案兼职多能，同时负责权限划分。例如，北京总部员工使用考勤方案A，由张三管理；成都、武汉、重庆员工使用考勤方案B，由李四管理。
- 思路2：考勤组专职专能。考勤方案仅负责规则制定，数据管理由考勤组独立负责。例如，北京总部员工属于考勤组1，由张三管理；成都、武汉、重庆员工属于考勤组2，由李四管理。
从自由度看，思路2在自由度和效率上优于思路1，类似于职场中的专职专岗，职责明确，工作安排灵活。
第三是扩展性。如果体验性和灵活性无法兼得，需考虑当前架构设计的可扩展性，确保以最小成本进行后期扩展，避免前期成本低但后期难以扩展的方案。
排班管理是考勤的核心功能之一，不同行业/企业需求各异。例如，制造业排班可能按时间规律性交替或按任务量调整；复杂度高时，员工只需选择白班或夜班。门店连锁行业则常见小时工不固定上班时间，正式员工常支援、调店/调班。
延伸场景包括按人员排班、按任务排班、按小时排班，支援调班、调店调班等，以及自动规律性排班和指定周期内自动复杂排班。
如果当前实体关系架构，不支持快速扩展，则需考虑调整。
总结一下
本文主要分享了如何将构想转化为具体的实体架构设计，介绍了设计的六步：
第一步：构建场景化产品架构：基于用户场景，抽象产品结构。关键动作是基于用户场景绘制全景产品架构图；方法论是【以终为始，全面设计；以始为终，最小闭环】。
第二步：构建关键角色流程：依据角色工作流，抽象产品流程。关键动作是明确产品的所有服务角色，根据产品阶段确定角色优先级，并绘制关键角色流程图；
第三步：提取关键实体：从产品架构与流程中提取所有关键实体。关键动作是找出产品架构与角色流程中的所有关键名词；
第四步：关联实体关系：对不同实体，建立相应的关联关系。关键动作是把所有关键名词用三种关系（即1对1/1对多/多对对）进行关联，让它们相互实现协同；
第五步：丰富实体设计：补充缺失实体，完善实体关系和属性。关键动作是查缺补漏实体关系，该加则加，该删则删；
第六步：场景验证与调整：根据用户场景和需求，验证并调整实体结构的扩展性。关键动作是收集足够需求场景，进行逐一验证，并在体验性、灵活性与扩展性之间进行权衡取舍。
