本文属于郭东白架构课学习笔记系列。

四 架构规划：

1为啥要做统一语义？

郭老师以电商商品案例，介绍了不同 角色对于实体商品、虚拟商品的差异，每个角色真正最在乎的，其中只是自己的需求被准确地满足。

  对于架构规划而言，统一语义的终极目标只有一个：项目所有参与方的需求能够被无损地表达、记录和传递，然后通过架构活动实现出来。

因为有了统一的语义，我们才能保证：

1.架构活动的目标，能够清晰传递并分解给每个参与者；

2.所有参与者的诉求，能够被准确地表达、记录和传递；

3架构活动的目标和所有需求能够反映到整体的架构规划中，并且能够被无损地拆分到多个子领域的任务中；

4.需求方能得到执行者的真实反馈，从而对整个架构活动的产出有个合理的期望；

5每个子领域交付并组装好之后，能够语义契合、相互兼容，最终符合架构活动的整体目标。

统一语义的目的不是为了统一参与者日常工作的语言，而是确保整个架构规划在一个逻辑完备且语义一致的环境中，能完成架构规划全生命周期的信息流转。

语义分歧的根源：

我们各自主观意识中形成的客体，以及我们能表达给其他人的关于客体的描述，以及我们试图在多个人中间建立的对这个存在的共识的认知，这三者是不等价的。而这种不等价，就是语义分歧的根源。  

  统一语义的完整过程 

第一步，发现不同的语境。

每一个交互场景其实都存在着多个角色，每个角色都有自己的独立语境。我们必须保留语义差异来提供差异化的流程和服务，但是也不需要引入太多的分支而给用户带来不必要的复杂性。

第二步，定义概念。一旦发现了一个新的语境中，存在词语表达相同但语义不同的概念，那就需要准确描述这些概念，更要准确描述这个概念背后的场景。

第三步，语义建模。当完成了单个概念的定义后，就需要把不概念引入到同一个语境中，也就是将两个不同的语境进行合并。

第四步，反馈修正。一旦形成了统一的语境，你就需要跟所有参与者确认这个统一语境的正确性。

第五步，公布、维护和使用统一的语境。指的是不断使用和打磨实体定义，最终为企业带来统一语境。这个过程就是从自然语言、到需求描述、到域模型定义的过程，未来也会延申到接口定义、模块设计、代码实现、上线使用等。

统一 语义而不是收集工作是郭老师认为架构师在这个环节真正要创造的价值 。这也是架构师的一个基本技能。其实大多数时候，当你找到了问题的根因，也就找到了解法。

   需求确认

     需求确认与统一语义的过程是密不可分的。需求确认是在统一语义赋能之下进行的，所以两者并不是先后顺序的关系。

   统一语义的主要场景和目的，就是对目标进行无损地分解和传递，以及理解、表达和传递参与者的诉求。那么需求确认，则是在统一的语义之下，将这种诉求继续无损地分解成研发人员的执行任务的过程。

  准备工作：

 首先要从产品定位的角度来梳理。

第一是客户，也就是为你整个架构活动买单的人（公司内部通常是架构活动的赞助者）。

第二是用户，他们是最终产出的软件产品的使用者，也是你创造的用户价值的受益者。

第三是核心场景，比如客户 / 用户在这个架构活动中的核心诉求是什么？他们因为什么价值而买单？这些需求将会在哪些场景中出现？

其次要从执行者定位的角度来梳理。

第一是执行团队，也就是架构活动的相关执行团队。你需要确认他们将会为哪些用户角色服务，可以为这些角色创造什么价值。第二是执行域划分，也就是每个执行团队所负责的领域。你特别需要关注的是执行领域之间互相重叠的部分，以及没有被任何执行领域覆盖到的部分。第三是需求承接方。除了架构活动中已知的执行者外，整个公司内部，谁应该、谁愿意、谁有能力或者谁有带宽承接某个需求呢？

最后是取舍规则：需求的优先级，哪些需求是必须完成的？

第三是隐含的技术需求。

问题域划分

需求确认的过程，也是从问题域到执行领域的映射过程。

问题域和执行域的划分，不能靠你的想象，而必须在多方参与下对事实形成一个准确的描述。从形成统一的问题域模型，再到问题域划分，最后到执行域的划分，一次迭代肯定没法完成。

从项目目标到需求的映射过程

需求评估  你需要准确区分最小必要的需求和无关紧要的需求。只有那些与项目目标形成因果关系的强依赖需求，才是属于架构活动的需求。

   这个梳理过程，之所以要放在问题域和执行域划分之后，是因为需求属于问题域的范畴，而需求的执行则属于执行域的范畴。

砍需求是个非常得罪人的事情，拉队友 。你做这件事情必须要有个同盟，也就是与需求对应的、问题域映射到执行域的负责人。因为在砍掉不必要的需求上，你们两个人的利益是一致的。你为了整个架构活动的成功，他则是为了控制自己领域的风险。你可以站出来表达比较客观的立场，而他则可以帮助你证实这个立场的合理性。

过程 关注：第一是需求的必要性，这个需求绝对有必要吗？与整体目标是因果关系吗？架构规划最忌好大喜功。第二是需求的正确性。需求是否和架构目标相匹配？需求不正确的情况在架构活动中频繁发生。第三是需求合理性。第四是需求的可达性。这个跟前面 一节类似。第五是需求的承接方。

需求到承接的映射

你需要跟每个执行团队，逐个确认他们是否是某个需求的承接方，这是你这个架构师在架构规划前必须确认的大图。

待解决的问题冲突：你会发现有些需求有好几个承接方，而有些需求却没有一个承接方。有些高优先级需求的对应执行者，没有任何研发带宽；而有些低优先级需求的对应执行者，却有充足的带宽。

第一，优先级的冲突。第二，定位的冲突。第三，团队和个人的冲突。第四，边界冲突。还有决策权的冲突等。通常可以总结如下：1.多个团队争夺有限的资源；2.多个团队争夺生存空间；3.无法调和的个人与团队之间的矛盾；4.短期内不合理的组织和决策结构。

  架构师必须保持开放心态，你没有决策权，更多是技术视角，其它的才培养、团队稳定性、成本控制、商业竞争、监管等可能不知道或者信息不对称。当前 阶段不怕暴漏问题，当前理不清就是给后面埋雷。

还是从道的层面，尊重人性，先在“我们要解决什么问题”和“怎么分解问题域”上达成共识。

边界划分 

边界划分的信条

上节是非常粗粒度的任务划分，本节进行任务边界的划分的准备。

信条一：任务边界可以打破现有的执行边界。

允许你在架构活动中打破这种边界，从而找到全局更优的架构设计。郭老师举例是物流查询，不必没个系统维护一个，提供公共的查询即可。

信条二：任务边界划分有确定的决策优先级

任务边界划分以最小化整体成本为第一优先级，但是不能牺牲项目目标的完成度。

信条三：最小化架构目标之外的抽象

等业务清晰稳定后可以阶段性重构。

抽象会提升系统的复杂度，自动削弱系统的迭代效率和稳定性。尤其是不了解细节或者业务场景处于探索期，复杂多变。减少不必要抽象简化架构规划的内容，减少执行者的工作量。

信条四：任务边界划分时要最大化隔离

隔离是把两个实体的相关的任务分开来，确保独立封装和实现。而抽象是在两个实体之上抽象出第三个实体，共享部分任务和实现。不过分抽象，急早隔离。

信条五：任务边界划分要面向未来最优

这个价值最大也是最难的，发现新的业务机会。

在任务 划分这个阶段，时间非常宝贵，不能拖太久。

任务梳理和粒度控制

是一个基于商业和技术环境的理性的思考决策。

在独立性假设之下，真正导致失败的正是你的最软肋，也就是架构活动中成功概率最低的强依赖。

锁定项目必保需求的交付资源

     一旦任务边界确认，那么就必须迅速锁定所有必保需求相关的资源。除了研发人员外，还包括业务、产品、研发、流量入口、发布窗口，甚至营销资金池。通常研发人员是最需要竞争的。

    一旦确认了规划请立即把大家聚在一起去做技术规划。告诉大家项目中都有哪些机会，这个画大饼阶段，如果别人都在画大饼，你不去画大饼就混不下去 ，就是之前的尊重人性，激发参与度意愿。项目的成功概率跟参与者的意愿度和投入度的关系更大一些，跟这个人的能力关系略小一些。   

郭老师又讲了霸道跟王道的区别，你可以邀请决策者来强压，这就是霸道。在一个冲突环境中你以最大化项目的成功概率为基础，做出决策，并引导大家达成共识，这就是行王道。

规划确认

到目前距离项目启动仅剩一步之遥，属于架构规划最后一个环节，规划确认是控制风险的重要机会。是保障交付的重要手段。是为团队和企业沉淀知识的重要时机，会产生大量架构文档。

  规划确认包含八个部分

规划确认过程中的每一个交付项，比如用例文档、必保任务、领域模型、API 设计、消息和数据流、整体交付节奏和完整性验证等，都指向同一个目的，即提升交付的确定性。这也是架构规划的实质。

组织用例文档

组织用例文档用例文档是关于交付内容的最简洁的描述。它的作用是描述架构活动中某个团队或者小组要为某个用户角色，在某个场景中，创造出某种价值。作用是确保所有研发人员都能对各自所交付的单元目标有清晰的认知

最顶层的用例最多也不能超过十个，还要将其整理成一个文档。

确认必保任务的交付节奏

我们需要收集所有必保任务，并确认任务分配和交付排期。最终，我们需要通过这个工具来跟踪所有必保任务的交付情况。 需要注意的是，这些必保任务也要和用例形成关联关系。

确认领域模型

你必须让最终的执行者来确认领域模型。

确认API

建议你在 Swagger Review 时，要尽量动员测试人员，让他们加入进来，并及早给出修正建议。

确认消息和数据流

在互联网时代，数据资产和商业分析团队永远是核心场景。如果做错了，未来还是要改。所以越早请相关方参与到设计的确认中，对数据服务的质量提升就越大。

确认强依赖任务的交付节奏

我承诺，只要依赖方能在 XX 年 X 月 X 日前，按质量完成所承诺的 API 和数据流。那么我也以我的口碑、年终奖和晋升担保，我会在 XX 年 X 月 X 日，按质量交付我的所有API 和数据流。

确认整个架构规划的完整性

整个架构规划的完整性确认，需要测试和相关团队核心人员的介入，从而确保核心场景的核心用例能被现有的功能所覆盖。同时也要确认 API、消息、数据是完整和兼容的，整体集成风险是可控的。

最终我们要达到的结果是有人有图有承诺，没个模块都有对应的owner.

   规划确认环节的王道，就是通过精细规划来控制风险，保障全面启动前交付风险的最小化.

将注意力放在核心场景、强依赖和交付主链路上。在架构规划中，架构师的责任不是让目标更伟大，而是要确保交付风险的最小化。不要不控制项目范围，这样既不符合互联网时代小步迭代的原则，也不符合系统论中复杂度控制的原则。