郭东白的架构课_38_28节点四架构规划之确认规划完整性
你好，我是郭东白。
这节课我们讲架构规划的最后一个环节，也就是规划确认。
在上节课我们已经梳理了一组必保需求，然后从这种需求中推导了一组任务。
并且我们以最大化某个项目目标的方式把这组任务分配到了执行团队中。
完成了这些工作之后呢，我们距离整个项目的正式启动就只一步之遥了。
第个重要的环节就是对整个架构活动的规划做确认。
规划确认这个环节的价值主要有三个。
第一，它是控制风险的重要机会。
第一，它是保障交付的重要手段。
第一，它是为团队和企业沉淀知识的重要时机。
因为在这个环节中，你和参与者会产生大量的规划文档，把这些文档将会是知识沉淀的利器。
可以说，通过架构规划中的确认环节来控制风险和保障。
交付。
就是我们在这个环节的核心关注点。
那么接下来我们就详细讲讲这个过程，一共分为八个部分。
第一部分定稿架构规划文档。
在规划确认之前，你已经收集了几乎所有跟架构规划相关的文档。
那么规划确认，也就是定稿架构规划文档的过程。
在定稿的过程中，你可能会跟不同团队企业外部的专家产生很多交货。
在这个时候你就需要跟执行者确认规划内容。
因为之前收集的是你规划的输入，而不是执行者的承诺。
所以在这个时候，你需要把输入转化成可行且具约束力的规划。
架构师的角色呢有点像律师。
除了最小化交互风险外，我们还要确保所有参与者有能力且有意愿履行他们的责任。
怎么确保呢？答案就是为参与者拟定一个合同，这是一个用提升交付确定性嵌实有效的工具。
这划确认过程中的每一个交付项，比如说用例文档必保任务啊，领域模型API设计消息和数据流、整体交付、节奏和完整性验证等都指向同一个目的。
那就是提升交付的确定性，这是架构规划的实质。
第二部分组织用例文档。
用例文档呢是关于交付内容最简洁的描述。
它的作用是呢描述架构活动中某个团队或者是小组要为某个用户角色在某个场景中创造出某种价值。
举个例子，商家团队呢要为中小商户在店铺经营的过程中提供有明确行动点的生意参谋功能，从而提升商家的经营效率和成交额。
需要格外注意的是，无论是写用力还是用一张图来表示用例，都需要避免堆积在一个架构活动中，不论是十个人还是上百个人参与，最顶层的用力最多也不能超过十个。
我们可以把这些用例组织成一个树状结构，从粗到细有数百个节点。
但是到了最顶层节点，最多不能超过十个。
这些节点是你作为架构师需要保障交付的价值，所以必须跟架构活动的目标相匹配。
如果一下子拿出上百个价值点去跟决策者和赞助者确定，要知道他们根本就没这个时间。
当然，并不是说我们不需要关注细节，一个节点可能细分成十个子节点，甚至继续细分成更多层。
但是从交付保障这个层面来说，我们只需要保障顶层的十个节点，以及这十个支点节点之间的强依赖就行了。
其他的子节点需要相应人员去保障交付。
在互联网时代，架构活动是一个时间高度紧张、交付风险极大的场景。
你作为一个架构师，不应该去关注几十甚至上百个节点的交付情况。
这些用例描述的作用时呢，确保所有的研发人员能够对自己所交付的单元目标有清晰的认知。
那我们刚才例子来讲，在这个把多个业务的商家工具做整合的架构活动，要知道你的作用呢就格外重要。
想想看，整合之后，每个垂直业务型的商家都能通过这个大一统的商家工具、生意参谋的功能来获得各自清晰的行动点。
而喽度量这些行动点的办法呢，就是提升商家经营效率和成交额。
就像我们上个模块中提到的，关注商业价值是架构是最重要的生存法则之一。
那么在架构规划中，我们必须要锁定整个架构活动的商业价值。
不过有时候呢也没必要这样做，因为整个架构活动就只有一个价值。
比如说稳定性治理，审计合规或者是商业模式升级。
对用例的描述呢，除了要尽量简洁之外，还需要把它整理成一个文档。
这样的话呢几乎所有人都能通过这些阅读用例呢而获得宏观视角。
而具体每个场景的细节描述和需求。
文档呢可以通过链接记录在另外的文档之中。
我曾经见过上百页的用例文档，读者呢会很快迷失到细节里。
我不太相信呢有人能完整读一遍这样的文档。
第三部分确认必保任务的交付节奏。
在架构规划的环节呢，我们还需要重新整理一遍。
在任务边界划分环节所做的具体的任务描述，并且呢要确保这些必保任务录入到鸡爪之类的工具中。
借助这个工具呢，我们需要收集所有的必保任务，确认任务分配以及确认交付排期。
最终呢我们需要通过这个工具来跟踪所有必保任务的交付文档。
需要注意的是，这些必保任务也要和用例形成关联关系。
由于这个环节呢是标准的研发流程，我们这里呢就不赘述了。
第四部分确认领域模型。
同样在这个环节中，你一直在准备的域模型也是一组输入。
那么现在你就需要完成定稿，这是一个统一语义的过程。
整个架构活动就只能有一个问域域型型虽不不同的执行者可以帮你梳理领域模型。
但是你必须把整个域模型整理到同一个语义环境中，这是对于架构活动中要解决问题的准确描述。
另外，你必须让最终的执行者来确认领域模型。
因为之前保帮你起草领域模型的，不一定是最终的执行者。
第部分确认认PI,有了用力文导必保任务和领域模型。
接下来呢就可以请各个团队完成API设计了，这是主要使用的是reasstful架框架。
那么swgger呢就是一个非常好的选项。
相比呢swagger的优点有这么七个，第一呢是有约束性，你是一个律师，那你就要看执行方能提供什么样的服务呢？第二呢是易读易用。
对于大多数程序员来说，读代码呢要比读文档更方便啊，第三呢是有copy right和ownership.研发人员呢其实是非常在意自己的口碑的。
一般比较资深的研发人员会在API定义上下很大的功夫，不像vicky呢很容易变成一个group文档。
第五呢是有投入连swegger er不想写或者写不出来的人，估计你未来也很难撬的动，甚至至也用不上这样的人。
所以在swagger上的投入，能让你提早发现资源和能力上的问题。
第五呢是规范性。
好，很容易呢在团队中的标准化掉。
第七是可测试测试性。
好，你很容易验证他的完整性。
第七是长期回报大光架构活动的本身对定义者本人的价值就很大，可以帮助他想清出问题。
而对于依赖这个API人的价值那就更大了，他可以制早做mock测试啊，及早给出反馈意见。
这样的话呢能避免在很晚的时候才发现集成问题。
长期来看呢，可以让整个集团形成良好的设计习惯，从而提升整体API的质量。
这是呢典型的一个有福利的编程模式。
顺便提一下呢，测试这个职能呢并不是为研发人员服务的，而是为用户服务的。
在业务内部测试人员是为产品服务的，而不是研发服务的。
所以呢我建议在swagger review的时候，要尽量动用测试人员，让他们加入，并且及早给出修正建议。
第六部分确认消息和数据流。
在确认好API之后，接下来呢就需要确认消息和数据的流转了。
也就是某个角色在某个时间能为某个使用方提供某些消息和数据。
消息是除EPY调用之外，服务之间最常见的通讯机制，甚至说呢是过分常见了。
事实上，我一直在怀疑过去大多数利用消息结果的场景，在今天的计算能力下，到底还是不是一个很好的设计模式。
尤其是对一个体量比较小的公司来说，消息队队列带来的编程维护状态查询和故障恢复的场复杂性呢，一般来说是不值得采用这样的设计。
不过呢我没有在百人规模的初创公司工作过，也没有什么发言权。
欢迎有经验的同学在评论区分享一下。
或在大公司里呢消息呢也是一个非常不对等的合作机制。
往往呢某个负责核心实体的团队比较强势，一般通过消息机制和其他服务解耦来降低稳定性的分析。
这个团队呢是消息的生产方，只管发送消息。
而接受方呢也自动认为消息队列永远是高可用低颜值和不丢失的去。
怎么做到这一点呢？不论是发送方还是消费者，似乎都不太关心，往往是消息积压之后才跳出来做各种的清晰操作。
无论如何呢，消息机制呢呃在很多需要解耦、人工审核或者风控，这样的异步场景呢还是很有必要的。
你作为一个架构师呢，也应该关注架构活动中消息机制的设计和使用。
不过多数时候呢，你只需要确认消息的生产和消费机制的畅通，不让他们影响现有的场景就行了。
而通过消息通讯的双方就需要将消息的内这种发送频次、消息的延迟要求，还有监控机制密等机制，以及消息的确认模式方式达成一致。
总体来说呢，很多公司的消息机制呢是缺乏规范性的，治理起来呢非常困难。
我呢不太建议你把消息机制作为一个数据传输的首选机制。
互联网时代呢数据是个核心资产，所以上线不仅仅是功能上线，还有保障监控、数字工作台、实时以及离线业务分析等能力的同时上线。
与此同时呢，数据的采集、精细整合以及加工可视化的质量监控报警的能力，在这个阶段呢也需要确认完成。
这是个常规工作，没太大的技术难度，难的呢是保障资源投入、模型质量以及数据质量。
所以如果在这个阶段呢，就早早规划呢会省去后续很多难度。
在大型活动里呢往往会碰到数据共享这样一个比较基础的问题。
哪怕公司内部呢，有时候数据据拥拥者者呢愿愿意分享给拥他的团队。
有的候候是出于管控和数据安全的担心。
不过更多的时候呢是为了维护团队的利益。
尤其是在那些比较喜欢赛马的企业。
因为参与赛马的团队呢，本质上呢是个竞争关系。
那么有先发数据优势的团，对的，肯定不太乐意把自己的实时数据分享出去。
但有些架构活动呢就是要求团队之间做数据打通，那么到底打通什么呢？就必须在这个阶段讲的明明白白。
不过呢你作为一个架构师在是否可以分享以及分享什么这件事情上是没有决策权的。
对于数据分享的内容和范围这件事最好由决策者亲自排板，并且在走正式的邮件审批流程才行。
如果说呢数据分享机制还要通过一个数据中台或者数据仓库，那么收仓的同学呢也必须参与到合同确认的环境中，来确保数据的生产方、管理方和数据的使用方在各个方面达成一致。
这些方面面呢包括买点要求、指标定义，必须支持的分析场景，还有模型定义数据局、行性和准确性，以及数据清洗分工和数据权限管理等等。
在互联网时代呢，数据资产和商业分析团队永远是核心场景。
你做错了，未来还是得改。
所以呢，越早请相关方参与到设计确认中来，对数据服务的质量提升呢就越大。
第七部分确认强依赖任务的交付节奏。
最终呢，你真正想得到的呢，就是所有的执行者都能说这么一句话。
我承诺只要依赖方在某年某月某日中来对质量完成所承诺的API和数据流。
那么我也以我的口碑、年终奖和晋升担保，我会在某年某月某日按质量交付我所有的API和数据流。
哈哈。
嗯，不过呢这种承诺呢其实是不太现实的。
不过过程管理工具呢会帮助你完成依赖梳理、交付项描述，还还有时承承诺的梳梳理和跟进。
这句话呢其实呢也反映了项目完成的一个常见风险点，那就是强依赖任务的交付。
首先通过依赖结果和swagger的应用，能让你并行处理一些工作。
但是真正的集成以及对异常情况的处理需要强依赖，任务完成之后才能进行。
所以，确认强依赖任务的交付节奏是你项目经理和执行者在各个用力层绩上都要进行的任务。
第八部分，也就是最后一部分确认整个架构规划的完整性。
整个架构规划的完整性确认呢需要测试和相关团队人员的介入，来确保核心场景的核心用力能被现有的功能所覆盖。
同时也要确认API数据消息是完整和兼容的，整个的基争风险呢是可控的。
在这个环节呢，我一般不太注意边界条件的处理，主要呢是担心大家会把过多的注意力分散在较小，甚至是比较难的异常情况处理上。
而呢核心场景呢或强依赖任务的处理上投入都不够。
我一般呢会让团队内部呢树立边界条件。
当他们发现其他团队的重大风险之后，才拿到整个项目组的层面来讨论。
我在这个环节呢反倒不太关注重大风险了。
原因呢有两点，一呢是大多数工作呢都做在这前面了。
二呢是你的注意力，没办法关注到领域内。
所以领域内的风险呢，你需要交给各个执行方去解除。
最终呢我想达到的结果呢，就是有人有图有承诺，这才算是合同签署完毕。
需要注意的是呢，这张图要尽量完整，每个模块呢都有一个owner,也就是我们在边界划分里确认的执行者。
每一条边不论是API、调用数据流还是消息机制，都会有一个人承诺。
我会在某年某月的某一天完整交付给你依赖的完整的一条边。
好了，今天的内容呢就是这么多，我简单的总结一下，到这里呢你可能已经总结出来了。
规划确认环节的王道呢，就是通过精细规划来控制风险保障，全面启动前交付风险最小化。
那该怎么做呢？答案呢？还是靠正确的取舍，把注意力放在核心场景，强依赖和交付主链路上。
同时呢也尽量把这个确认环节变成一个分布式的并行确认的过程，一来可以争取时间，二来可以提升参与者担当和投入度。
远大的规划呢是由目标来决定的。
在架构规划中，你这个架构师的责任不是让目标变得更伟大，而是要确保交付风险的最小化。
我见过太多激进的架构师了，他们不但不控制项目的范围，反而在规划环节持续放大范围。
这么做呢，既不符合互联网时代小步迭代的原则，也不符合系统论中复杂度控制的原则。
有些大项目是很空的，因为我们没办法把一个大项目拆成一组小项目，所以就搞了一些大项目出来。
而一个项目中呢，最可怕的是架构师呢把项目规划越来越大，恨不得让公司所有的研发人员都参与进来。
你可千万不要这么做。
最后呢是我们的思考题环节，还是呢老规矩三个思考题呢，你可以选择你认为最有价值的一道题来分享一下。
第一题呢作为架构师，在冒险精神的价值观下，你认为最小可用的规划是什么？你会选择忽略哪些环节呢？为什么？第二题呢，作为执行者，你最反感什么样的规划？第三，计划永远赶不上变化，哪怕是再完美的规划也敌不过变化。
你见到过最夸张的变化是什么？这种变化可以通过规划来实现吗？为什么？如果这节课对你有帮助呢？欢迎你把课程转发给你的同事和朋友啊，继续打了我的小广告啊，我刚刚看了抖音号呢啊我还是已经发表了一些比较新还是没那么成熟的观点呢。
我欢迎大家在抖音上搜索郭东白，并且关注，也欢迎你的批评指正，我们下节课再见，拜拜。