规划确认，也就是定稿架构规划文档的过程。规划确认环节的王道，就是通过精细规划来控制风险，保障全面启动前交付风险的最小化。
在定稿的过程中，你可能会和不同团队、企业外部专家产生诸多交互。这个时候你就需要与执行者确定规划内容。因为之前的收集主要是作为规划的输入，而不是执行者的承诺。所以你就需要把输入转成一个可行且有约束力的规划。
架构师的角色有点像律师。除了最小化交付风险外，还要确保所有参与者有能力且有意愿履行他们的责任。怎么确保呢？答案是为参与者拟定一个合同。
用例文档是关于交付内容的最简洁的描述。它的作用是描述架构活动中某个团队或者小组要为某个用户角色，在某个场景中，创造出某种价值。避免堆积，最顶层的用例最多也不能超过十个。
这些用例描述的作用是，确保所有研发人员都能对各自所交付的单元目标有清晰的认知。
在架构规划的环节，我们还需要重新梳理一遍在任务边界划分中，做出来的具体的任务描述。并且要确保这些必保任务录入到了 Jira 之类工具中。
确认领域模型，你必须让最终的执行者来确认领域模型。因为之前帮你起草领域模型的，不一定是最终的执行者。
确认API，在 Swagger Review 时，要尽量动员测试人员，让他们加入进来，并及早给出修正建议。
在确认好 API 之后，接下来就要去确认消息和数据的流转了。也就是某个角色在某个时间能为某个使用方提供某些消息和数据。
很多公司的消息机制缺乏规范性，治理起来又非常困难。因而我不建议你把消息机制作为一个数据传输的首选机制。
确认强依赖任务的交付节奏，是架构师、项目经理和执行者在各个用例层级上都要进行的任务。
整个架构规划的完整性确认，需要测试和相关团队核心人员的介入，从而确保核心场景的核心用例能被现有的功能所覆盖。同时也要确认 API、消息、数据是完整和兼容的，整体集成风险是可控的。
最终我们要达到的结果是有人有图有承诺，这才算是合同签署完毕。需要注意的是，这张图要尽量完整，每个模块都有一个 Owner，也就是我们在边界划分里确认的执行者。
此文章为6月Day1学习笔记，内容来源于极客时间《郭东白的架构课》
