通过架构规划中的确认环节来控制风险与保障交付，就是在这个环节的核心关注点。具体而言，规划确认包含八个部分。
1、定稿架构规划文档
在定稿的过程中，你可能会和不同团队、企业外部专家产生诸多交互。这个时候你就需要与执行者确定规划内容。因为之前的收集主要是作为规划的输入，而不是执行者的承诺。所以你就需要把输入转成一个可行且有约束力的规划。
架构师的角色有点像律师。除了最小化交付风险外，还要确保所有参与者有能力且有意愿履行他们的责任。怎么确保呢？答案是为参与者拟定一个合同。
这是一个用来提升交付确定性的切实有效的工具。规划确认过程中的每一个交付项，比如用例文档、必保任务、领域模型、API 设计、消息和数据流、整体交付节奏和完整性验证等，都指向同一个目的，即提升交付的确定性。这也是架构规划的实质。
2、组织用例文档
用例文档是关于交付内容的最简洁的描述。它的作用是描述架构活动中某个团队或者小组要为某个用户角色，在某个场景中，创造出某种价值。
需要格外注意的是，无论是写用例，还是用一张图来表示用例，都需要避免堆积。在一个架构活动中，不论是十个人还是上百人参与，最顶层的用例最多也不能超过十个。
对用例的描述除了要尽量简洁外，还要将其整理成一个文档。这样的话，几乎所有人都能通过阅读这些用例来获得更为宏观的视角。而具体的每个场景的细节描述和需求文档，可以通过链接记录到另外的文档中。
3、确认必保任务的交付节奏
在架构规划的环节，我们还需要重新梳理一遍在任务边界划分中，做出来的具体的任务描述。并且要确保这些必保任务录入到了 Jira 之类工具中。借助这个工具，我们需要收集所有必保任务，并确认任务分配和交付排期。最终，我们需要通过这个工具来跟踪所有必保任务的交付情况。 需要注意的是，这些必保任务也要和用例形成关联关系。
4、确认领域模型
同样，在这个阶段之前，你准备的领域模型也是一组输入。那么在规划确认这个环节，你就需要完成定稿。这是一个统一语义的过程，整个架构活动只能有一个问题域模型。虽然不同的执行者可以帮你梳理领域模型，但是你必须把整个领域模型整理到同一个语义环境中。这是对于架构活动中要解决的问题的准确描述。另外，你必须让最终的执行者来确认领域模型。因为之前帮你起草领域模型的，不一定是最终的执行者。
5、确认 API
有了用例文档、必保任务和领域模型，接下来就可以请各个团队完成 API 设计了。如果架构活动中主要使用的是 RESTful 框架，那么 Swagger 就是一个非常好的选项。
相比 Wiki，Swagger 的优点是：
- 有约束性。我们刚才把架构师在这个环节的角色看作律师，那么我们就要看看执行方能提供什么样的服务。
- 易读易用。对于大多数程序员来说，读代码要比读文档更便宜。
- 有 Copyright 和 Ownership。研发人员非常在意自己的口碑，一般比较资深的研发都会在 API 的定义上面下很大的功夫。不像 Wiki，很容易变成一个 Group 文档。
- 有投入度。连 Swagger 都不想写或者写不出来的人，估计你未来也很难撬得动他，甚至也用不上这样的人。所以在 Swagger 上的投入，能让你提早发现资源和能力上的问题。
- 规范性好，很容易在团队中标准化掉。
- 可测试性好，容易验证其完整性。
- 长期回报大。仅架构活动本身，对定义者本人的价值就很大，可以帮助他想清楚问题。而对于依赖这个 API 的人来说，价值就更大了。他可以及早做 Mock 测试，及早给出反馈意见，避免在很晚的时候才发现集成问题。长期来看，还可以让整个团队形成好的设计习惯，从而提升整体的 API 质量。这是个典型的有复利的编程模式。
6、确认消息和数据流
在确认好 API 之后，接下来就要去确认消息和数据的流转了。也就是某个角色在某个时间能为某个使用方提供某些消息和数据。消息，是除了 API 调用外服务间最常见的通讯机制，甚至可以说是过分常见了。事实上我一直在怀疑，过去大多数利用消息解耦的场景，在今天的计算能力之下，到底还是不是一个好的设计模式。
这是个常规工作，没太大的技术难度，难的是保障资源投入、模型质量和数据质量。所以如果在这个阶段就及早规划，会省去后续很多麻烦。
7、确认强依赖任务的交付节奏
虽然通过依赖解耦和 Swagger 的应用，能让你并行处理一些工作。但是真正的集成，以及对异常情况的处理，还是需要完成强依赖任务后才能进行。所以确认强依赖任务的交付节奏，是你这个架构师、项目经理和执行者在各个用例层级上都要进行的任务。
8、确认整个架构规划的完整性
整个架构规划的完整性确认，需要测试和相关团队核心人员的介入，从而确保核心场景的核心用例能被现有的功能所覆盖。同时也要确认 API、消息、数据是完整和兼容的，整体集成风险是可控的。在这个环节，一般不太关注边界条件的梳理，主要是担心会把过多的注意力分散在较小，甚至是比较难的异常情况梳理上，而在核心场景和强依赖任务的梳理上投入得不够。
规划确认环节的王道，就是通过精细规划来控制风险，保障全面启动前交付风险的最小化。