如何画好一张架构图
Categories: 编程
[toc]
架构
架构是什么？
有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
架构的本质
架构的本质是管理复杂性。
架构的基本出发点是为了效率，通过架构的合理切分，让效率最大化。
- 架构的本质就是对系统进行有序化重构，不断减少系统的“熵”，使系统不断进化。
- 架构的本质就是对系统进行有序化重构，以致符合当前业务的发展，并可以快速扩展。
权衡取舍
- 内外部需求
- 以改善软件质量为目的的内在结构性变化
- 以满足客户需求为目的的外在功能性变化
- 系统实现
架构要表达的是什么？
- 业务架构
- 应用/系统架构
建模
建模是什么？
为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。
如何建模
建模图包括：
- 业务核心流程图
- 业务功能模块
如何做：
- 把文档读厚：大量的信息输入，同时探求可能性。常问自己：我是否已经具备了全局视野？
- 把文档读薄：归类汇总，形成大图。常问自己：边界是什么？输入输出是什么？
具体问题：
- 系统一定是给人用的，参与者是谁？
- 业务主要流程是什么？分支流程有哪些？
- 进一步归纳、演绎，抽象形成业务描述
建模的好处
- 业务共识：业务、产品、测试、研发大家讲一样的话，描述一样的事情
- 统一认识，减少沟通成本
系统建模
系统建模更强调职责，依赖，约束关系。
这张图为什么要这么画？层次如何划分？边界如何确定？
终极武器：所有的设计/逻辑模糊的点，将所有已知场景分别套入，自己讲给自己。
怎么画好架构图
套路
- 高内聚，低耦合。
- 每次从一个角度来切，然后换多个角度来审视。
- 通过组合、拆分来精化、优化模型与设计
- 关键审视点：
- 耦合性：减少模块间通信量（CTP搜索）
- 内聚性：功能单一化（租户/分销）
- 变化的隔离性：减少信息依赖，建隔离层、虚拟层
- 建模
- 业务建模，是从小到大，从局部到整体，自底向上的归纳、演绎的抽象过程
- 系统建模，是从大到小，从整体到局部，自顶向下的拆解、切分的抽象过程
架构图是架构在不同抽象层次的表达，是自然而然的过程。不是有图再有业务流程、系统设计和领域模型等
给谁看：
- 参与项目的各团队各角色（业务、产品、开发、测试、DevOps）
- 给项目之外的客户（IOC，北京奥组委，评审专家）
- 给老板（汇报，跨BU，跨团队协作沟通）
画架构图是为了什么？
- 解决沟通障碍
- 达成共识
- 减少歧义
- 团队内部和团队之间的协作、沟通、愿景和指导
抽象层次
按抽象层次分类：领域—>子域—>模块—>子模块一>包一>类—>方法
- 较低层次的抽象：应用内部包图、类图；某个领域：实体图、时序图、状态图、用例图等等；
- 更高层次的抽象：具有一定的复杂性，比如微服务架构，系统间的交互图，领域/子领域架构图，整个系统架构图
组成元素
架构图的组成元素？
- 方框、各种形状、虚实线、箭头、颜色（不同颜色代表什么意思）、文字
- 虚实线表达什么？组件类型，模块类型，层，服务，是否已经实现等？
- 箭头表达什么？数据流或关联关系？
- 交互类型可以是同步或异步的；关联类型有可能是指依赖、继承、实现
- 需要考虑内容术语一致性问题、碎片化问题、信息粒度大小的问题，以及图表的外观问题
如何评价架构图的好坏
- 内容术语一致、信息粒度大小一致，图例清晰，颜色类型统一，美观
- 图中的信息与相应的抽象级别相关，且满足利益相关者（合作方）的需求
- 一张好的架构图不需要多余的文字解释！受众有没有准确接收到想传递的信息
- 如果它所导致的疑问比它能解释的问题还要多，那么它就不是一张好的架构图
- 架构图应该帮助每个人看到大局，了解周围的环境，适当的上下文信息
- 架构图应该避免「只见树木，不见森林」