开发人员的画图技巧
本文最后更新于：1 个月前
开发人员的画图技巧
思维导图
思维导图又叫脑图，使用一个中央关键词或想法引起形象化的构造和分类的想法，是一种结构化思维的树形发散图。
技术人员一般使用思维导图做需求拆解、领域模型分析、业务/技术规划等。
平时技术栈的积累、读书笔记也可以通过思维导图很直观地表达出来。
思维导图的难点在于，看待一个事物有很多个维度，我们应该用什么维度去合理细分每个节点。
UML图
四个要点
- 要点一：聚焦关注点，关注粗粒度
- 要点二：清晰的业务边界
- 要点三：实体关系明确
- 要点四：穷举变化，避免过程遗漏
常用的有四类：类图、时序图、活动图、状态图
1. 类图
常用的有两种：第一是领域模型设计，第二种是表实体关系设计。
DDD（领域驱动设计）
我们都知道实体之间一般有四种关联关系，关联关系从强到弱依次是：
组合 > 聚合 > 依赖 > 关联
2. 时序图
时序图用于分析复杂业务流程，一般简单的CRUD并不需要画时序图。
时序图也不需要把所有时序都细化，
一句话：聚焦关注点，只关注核心时序。对于多个系统，有多条生命线。 注意一点，角色不是生命线，角色可以使用小圆点表示角色操作入口。对于时序过多的流程，可以合理拆分时序图，或使用水平泳道划分业务阶段，否则你的时序图会特别长，同事根本没耐心看完。
3. 活动图
活动图和产品经理出的流程图差不多，都是动态图，
活动图相对时序图关注更粗粒度的业务流程变化，其中一个活动可能包含多个时序。
活动图可以通过纵向泳道和横向泳道划分，纵向泳道表示系统，横向泳道表示业务阶段。
4. 状态图
状态图又叫状态机，表示对象的某个状态跃迁到另一个状态的集合，比如销售订单的订单状态、采购订单明细的采购状态、结算单的结算状态等。
状态图有两个因素需要我们关注——
- 状态：当前对象所处的稳定状态
- 跃迁条件：状态转移前触发的一系列过程
在对象的设计过程中，状态的枚举值不宜过多，状态过多时考虑拆分多个状态属性或使用多条记录代替。
表示状态的属性一般不超2个，避免有业务关联的状态（枚举值）产生复杂的笛卡尔积。
跃迁条件复杂的情况下，图不好表达双向状态转移，一般使用状态图+状态表来穷举描述状态变化。
编码过程中，注意状态迁移的时序问题，必要时做幂等处理，防止数据并发写产生的问题。
状态表是包含初态、次态的笛卡尔乘积二维关联表，避免分析过程遗漏。
架构图
（系统）架构图是为了抽象地表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图。
架构图的作用
一图胜千言。要让干系人理解、遵循架构决策，就需要把架构信息传递出去。架构图就是一个很好的载体。