结合用户核心场景将其对应场景进行抽象与拆分再结合事务用工作台去承载与数据用报表仪表盘去承载两个层面即可输出完整的产品架构图其可间接等同于产品的菜单路径设计即每个块就是一个一级菜单对应内容可做二级菜单与演化功能即给每个块标识优先级和分期即可一体化的一张图。 注意设计时遵循【以终为始全面设计；以始为终最小闭环】原则详情可见如何周内输出产品规划？。 二结构层实体关系解耦化 如果把一座城市当做一款产品看菜单路径场景化设计解决的是城市路径交通的问题保证路径简单清晰便于人们可快捷到底目的地； 实体关系解耦化解决的是应该有哪些建筑群哪些社区以及他们有什么样的内在关系保证当前居民居住幸福度的同时更需要考虑系统的健壮性与扩展性。
什么是实体？ 一个系统中具备 阿联酋电话号码列表 自身独特价值却又相互依赖才能产生整体功能价值的个体。比如部门员工商品订单等都是实体；而员工的入职规则员工的出勤规则也可以是实体。 什么是实体关系？ 实体之间的的内在关联保证相互之间的依赖联动更简单高效以此可共同作用服务于整体系统。 一般主要有三种实体关系对对多多对多。 比如一个部门有多位员工一个员工却只能归属于一个部门那它们就是对多的关系； 同时一个系统到底需要哪些独立的实体以及实体间的关系如何定义也就是我们所说的解耦还是耦合将会影响系统的健壮性与扩展性。同时一定会影响用户体验设计。
. 案例 作为一名考勤H期望通过H产品实现考勤规则的规范化与数据化则需设置员工的打卡排班加班补贴扣款外出/出差等规则。 如果给你提供四个方案你会觉得哪个方案体验更好呢？它包含两层意思一层是可设置满足你业务规则的系统规则；第二层是让你可简单快捷设置规则。 方案一以考勤组实体为核心辅以加班补贴扣款外勤补卡规则等个实体考勤组与个规则的关系是多对即一个规则可用于多个考勤组但一个考勤组只能有个类型的规则。同时只有核心实体考勤组有【适用范围】其他实体只是规则复用适用人员范围； 方案实体关系图 方案产品示意图 方案二没有核心实体考勤组加班补贴扣款外勤打卡等均是单独的实体相互之间完全没关系。