大家好，我是大龄码农，今天一起聊聊架构设计的规范：设计规范及评审规范，欢迎一起探讨、指正。
架构设计是整个项目的灵魂，好的设计往往能够事半功倍，这也是我一直提倡的要花超50%时间在架构设计文档上，做到慢也是快。
缺少架构设计规范会引发哪些问题呢？
- 当你自己在设计架构文档时，是不是想到哪，设计哪？缺少固定的规范，往往丢三落四。
- 当你在评审别人的架构文档，是不是总是被别人所牵引，你只能基于别人的大纲，思考实现细节是否可行？而这往往会遗漏重要的架构点。
以下为本人自己总结且常用的架构文档模板及要点说明，不管自己设计方案还是评审别人方案，都可以按照纲要判断是否遗漏。
架构文档示例
1 背景
- 业务诉求或遇到的问题
- 预估价值
- BRP 及 PRD 及项目链接
2 现状
2.1 整体交互
涉及系统的宏观架构，为架构师或技术经理早期规划
2.2 领域模型
涉及系统的领域模型，为架构师或技术经理早期规划
2.3 分层能力
涉及系统的分层能力，为架构师或技术经理早期规划
2.4 数据结构
涉及系统的数据结构，一般有技术文档沉淀的话可直接拿过来用
2.5 交互时序
涉及业务流程的详细交互，一般有技术文档沉淀的话可直接拿过来使用；该时序为分层能力的细化流程，但需要在交互上备注对应的能力名称。
要点说明：
- 黑色线表示强依赖，灰色线表示弱依赖，实线为同步，虚线为异步
- 交互对象至少涉及端 / 用户 / JOB/MQ/ 二方服务、内部服务、数据库、三方系统
2.6 核心类图
涉及服务的类图，一般有技术文档沉淀的话可直接拿过来使用；通过类图能够找到预留的扩展点或找到需要更改的类，类图可以比较粗略，需要包含核心流程上的类和方法，通过类图能够找到分层能力上的方法。
2.7 接口依赖
2.7.1 依赖接口
涉及业务流程依赖的外部接口，具体到接口所属团队、服务名称和接口名称即可，能与上面的交互时序关联上
2.7.2 对外接口
涉及业务流程对外暴露的接口，具体到服务名称和接口名称，能够与上面的交互时序和类图中接口对应上
2.7.3 消息依赖
涉及业务流程依赖的业务系统消息、binlog 消息，消息可以是外部的消息，也可以是内部发送的消息。能够与上面的交互时序对应上，同时能够在分层能力中找到对应的消息
2.7.4 对外消息
涉及业务流程对外发送的消息，包括业务系统消息、binlog 消息，能够和交互时序对应上，同时在分层能力找到对应的基础设施能力
3 方案
3.1 整体交互
整体交互有变动时必须有，更改后沉淀下来，作为下次现状使用
3.2 领域模型
领域模型有变动时必须有，更改后沉淀下来，作为下次现状使用
3.3 分层能力
分层能力有变动时必须有，更改后沉淀下来，作为下次现状使用
3.4 数据结构
数据结构有变动时必须有，更改后沉淀下来，作为下次现状使用
3.5 交互时序
红色线表示强依赖，蓝色线表示弱依赖，实线为同步，虚线为异步，如果为在现状交互时序上改动，需要基于上面现状时序加上变动
3.6 核心类图
红色表示新增，如果为现状类图上改动，需要基于上面现状加上变动
3.7 兼容方案
3.7.1 数据兼容
当数据结构发生变动时，需要考虑历史数据的兼容方案，为了保证系统的简洁性，不能一直做兼容方案，可以考虑数据清洗将数据转为新的格式
3.7.2 接口兼容
当涉及接口变动时，尤其是对 APP 端的接口，需要考虑接口的兼容，接口改动需要遵循开闭原则，只能新增出入参，不能改动出入参，甚至不能改变出入参的语义
3.8 监控方案
3.8.1 业务监控
对于比较重要的业务，需要通过埋点方式进行业务的监控，如果公司有统一的可观测平台，直接使用其扩展进行埋点，如果公司没有，建议异步方式对异常增加消息推送
3.8.2 数据对账
核心业务的交互，除了在链路里增加一致性方案（幂等 + 重试）保障数据一致性外，建议增加离线的数据对账，进一步确保系统的数据一致性
3.8.3 实时资损防控
如果改造涉及资损，如：结算、打款、退款等业务，建议接入资损平台，前提是有资损平台
3.8.4 接口审计
对于一些对外暴露的接口（如果获取登录验证码、无登录获取商品列表等）及核心的后台操作接口（如变动计费规则、变动权限、查询人员列表等），需要讲接口的调用接入审计日志，方便安全团队对其进行审查
3.9 影响范围
3.9.1 功能测试范围
开发人员需要将涉及的变动点列举出来，在测试用例评审时与测试人员的功能场景进行碰撞比对，从而保证不遗留测试场景
3.9.2 性能测试范围
针对变动的接口或流程，如果线上访问量比较高，需要进行性能测试，此功能需要开发人员进行评估
3.10 发布方案
3.10.1 发布脚本
配置脚本、TOPIC 申请、数据库脚本，需标明脚本执行的时机（在服务发布前执行还是服务发布后执行及脚本的执行顺序）、新建表标明数据的归档周期
3.10.2 发布顺序
顺序有两个，如果是跨部门的需求，需要评估团队的发布顺序，其次再评估内部服务之间的顺序
3.10.3 灰度方案
对于影响较大的变动，需要设计切流方案（切流的规则）及周期
3.11 接口文档
列举涉及的接口并以超链接方式跳转到接口详页，接口名称需要与分层能力中的能力对应上，另外接口文档一定要在正式开发前进行评审，避免出现重复接口、不规范的接口
4 排期
排期首先要按照阶段进行划分：方案设计及评审、开发、测试（含性能测试）、上线、灰度。
其中开发阶段需要将任务拆分到细化后的功能点级别，保证：单个功能点不占用太长开发时间、功能点之间可并行开发，以便多人开发时能够互不干扰。以支付宝账单对账功能为例，可拆分为：支付宝账单接口对接及数据入库、本地数据与账单数据双向比对、对账告警功能、差异数据页面展示、页面差异数据处理、页面重新对账。