2.1 条件
- 单个系统的多个模块（例如订单履约系统中订单、库存、商品等）
- 多个系统（例如订单履约系统和仓库管理系统）
2.2 推荐的表达方式
无论是什么样的表达方式，尽量使用图 文字说明的方式，让阅读者更容易理解。
2.2.1 实体关系图
表明不同领域之间的关系，是1:1还是1：N还是N：1，能清晰画出模块间关系需要一定的垂直业务沉淀和领域抽象能力。
（产品画到示例这个程度即可，更详细可以了解ERD图）
垂直业务沉淀：这属于知识层面的经验能力，只要去学就能学得到。例如我们要打造账号体系中的母子账号，母账号有超级管理权限，子账号可以被母账号分配权限，一个母账号可以关联多个子账号。那么母账号和子账号的关系就是1:N。同时还要考虑，1个子账号是否能对应多个母账号，业务层面有没有这样的需求，如果有就是N:N。
领域抽象能力：抽象能力不属于知识，是一种技能，要靠悟性和大量训练。最核心的是要有给领域下定义的能力。例如我们在做会员管理的时候，需要拆分账号和商家两个细分领域，就要给账号和商家下定义。
- 定义账号：账号是主要管授权登录用的，能不能被登录验证通过，就是账号领域的事情；包括如果想做第三方登录（如微信登录），这个只和账号体系打通就可以，跟商家领域就没有关系。
- 定义商家：商家则关系到很多业务能力，例如结算方式是先款后货，还是账期。
与此同时，账号和商家又要有绑定关系，商家和账号（母子账号）的关系是1：N。
再举一个例子，说明一下抽象定义的重要性：我们先看四个词，黑马、白马、河马、盒马，针对这个四个词我们应该怎么分类呢？
若定义一个类为：名字中带马的词，那他们都可以归为一类；若定义一个类为：按动物科属划分，白马黑马属于马科，河马属于河马科，盒马是超市不是动物。
不同的关系在产品设计上意味着什么?
- 领域A与领域B的关系为1:1，这是关系中最简单的，无论从A到B还是从B到A都能找到唯一值。
- 领域A与领域B的关系为1:N，从领域A触发的时候要有决策的逻辑找到领域B中的某个值。
- 领域A与领域B的关系为N:1，从领域A触发任一值都能找到唯一，反之则不是。
- 领域A与领域B的关系为N:N，不管从A到B还是从B到A都需要有决策的逻辑，这是关系中最复杂的，若能避免一定要尽量避免，避免不了一定要做好决策逻辑。
梳理清楚关系为什么那么重要？
- 能加强/外显对业务的理解： 领域的关系图能确保软件系统能够准确地反映业务逻辑，当你能够精准的画出领域关系说明这个整体是真的搞懂了，基本上这个关系上在了解清楚业务需求后瞬间形成的，如果你需要冥思苦想，说明功夫还不到家。
- 系统的可维护性： 更容易维护和更新，因为变更可以更精准地在领域模型中进行反映，能够有效的避免不同系统和模块间的撕逼，帮助划清产品边界。
- 模块化和扩展性： 不同领域之间清晰的边界和关系使得系统更容易进行模块化设计，同时也更容易扩展。这是高阶产品经理的必备能力，当你重构过几个系统以后才知道模块化和拓展性到底有多重要。
- 有助于团队协作： 帮助不同团队成员更好地理解系统的整体结构和各个部分之间的协作方式。如果你是系统负责人或某个项目的主产品，这个图能够很好的帮助各个领域的产品理解自己的逻辑，同时也能有效的帮助研发、测试无歧义的理解需求。
2.2.2 时序图
时序图：描述不同领域/对象之间的交互与通信。
- 谁在什么时候请求了谁的接口，返回是什么？
- 一个动作中包含了哪些业务层面的不可缺少的服务调用，否则就从头开始？
- 是同步返回还是异步返回等？
主体可以是不同系统，可以是同一个系统的不同模块，也可以是同一个系统的前端、后端（针对前后端分离的系统）。
大多数情况下时序图是研发侧在做技术设计时才会用到的，产品所画的时序图其实是没有办法真实体现技术的实现细节，但我认为他有其他图像不可比拟作用：与泳道流程图相比弱化了逻辑判断关系，但是强调了时间顺序，尤其在多个接口调用的先后以及表达同步异步关系上。
在复杂的B端系统中，产品经理一定要清楚以下情况，这些情况可能会限制功能设计。
- 不同接口的作用
- 大流程上接口调用的顺序
- 同步/异步的接口消息响应
举一个物流行业对接第三方物流服务商时经常碰到的场景：我们系统给第三方物流下单（可以理解为申请运单号）时，第三方物流系统同步返回的只有接口响应的成功/失败，这个成功/失败结果只代表了对方接收到了你的信息，只是通过了接口层面的一些基础校验逻辑，实际的能否真正的通过校验，拿到实际的运单号还未可知。
为什么会这样？第三方的物流系统可能是因为内部系统过于复杂不能同步返回，也可以他们也依赖了别人的系统。
因此第三方系统会在一段时间之后通过Webhook等方式回调给我方，告诉我们实际的结果。
这样一个比较简单的系统交互，用时序图 文字表示就再好不过：
3.1 条件
当一个方案需要新增/修改状态机，一般来讲改动都较大。
以我在电商供应链的工作经历中，状态机一般是和单据流同时出现的，之所以有单据流是因为要持续一段时间追踪某一件事，这件事会不停的变更状态来反映当前的事实。例如销售订单会记录「新建」、「待支付」、「已支付」、「待发货」、「已发货」、「取消」等状态。
当然状态机其实也广泛用于各种领域，软硬件结合的比如自动零食售卖机，纯软件的比如网路游戏中。
3.2 推荐的表达方式
我们常用的状态机叫做有限状态机。
有限状态机（Finite State Machine，简称FSM）是一种数学模型和计算机科学中的概念，用于描述系统的行为。它由一组状态、一组转移规则和一个初始状态组成。有限状态机可以处于这些状态之一，并根据输入执行状态转移。
状态机描述的是活动中状态的变化，突出的是「动作」引发「状态」变更，这对产品经理能力有3个要求：
- 关于动作(action)：要明确知道谁在什么时候触发的动作是什么
- 关于状态(status)：要有明确的预期动作后的状态结果是什么
- 关于整体：一个单据流的状态掌握绝不仅仅是只针对自己修改的部分，关键状态的变更有可能是牵一发而动全身，因此产品要掌握整体的状态变化，才可以产出一个高质量的状态机。
（产品经理掌握确定性的「有限状态机」即可，此类的状态个数是可穷举的，且动作引发的条件是可枚举的。）
（简单的状态机）
3.3 有限状态机实例
以「电商的销售订单支付状态」简单展示下状态机如何画如何表述。
在这种流程中一般会建议加上开始和终止，尤其终止表示了某个状态为终态，终态是不可以再变更的。
