郭东白的架构课27

你好，我是郭东白。上节课我们讲了统一语义和需求确认，这是架构规划的前两个环节。至此，多数的问题域都应该有且仅有一个执行域了。那么接下来，我们就来讲更细粒度的任务边界划分，这也是架构规划的第三个环节。

上节课我们讲到了从问题域到执行域的映射，是个粗粒度的映射关系。不过有些任务无法在粗粒度的划分下完成需求到执行的映射，比如我们上节课提到的边界冲突的情况。

总的来说，这种粗粒度的映射会面临三方面的挑战。如下：

1. 粒度划分是基于现有执行域的，这种划分导致我们的架构设计会受到执行团队组织结构的约束。也就是康威定律对架构设计的干扰。
2. 无论我们怎么努力，依然会在架构活动中碰到执行域划分没有执行团队，或者有多个执行团队的情况。
3. 执行域是非常粗粒度的任务划分，但部分有边界冲突的跨领域任务，需要在更细粒度的任务层面上做执行边界的划分。

那么如何应对这三方面的挑战呢？答案是进行任务边界的划分。

我们可以把这些需求拆分成研发任务，并分配给执行者。而这些任务的组合和边界，最终会决定长期的技术架构。因而这个步骤，可能是架构师能对长期架构设计产生最大影响的一个环节了。所以深度理解从需求到任务到承接的关系，以及学会如何分配自己的注意力，就是你这节课要掌握的重要技能。

那么怎么进行任务边界的划分呢？我们前面提到了架构环境建设。从根本上来说，如果能结合架构环境建设，在团队中建立架构信条，那么任务边界的划分就容易得多了。

那么这节课，我们先来讲任务边界划分应该具备的几个信条。下节课我们再来讲具体怎么做任务边界的划分。

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

我们先来区分一下“需求”和“任务”这两个概念：

• 需求是一个问题域概念，来自用户；
• 任务是一个执行域概念，来自内部的分工合作。

所以这个信条是指，任务分配虽然应当尊重当前问题域到执行域的映射，但却不需要完全遵照这个映射。在一个架构活动中，架构师更应该从用户思维出发，把任务交给能完成这项任务的团队。

这里特别强调一下，在架构活动中，任务边界的划分是暂时性的，不是永久性的。任务边界的划分不同于执行域的划分。执行域的划分是个组织分工概念。每个实体团队在组织架构中有明确的执行域定位。执行域的划分，关系到管理者和团队的利益，是个极为敏感的问题。架构师没有权力更改执行域的划分。

之所以强调暂时性，是因为这个任务边界划分，不一定影响长期的组织边界和团队定位。在这个短暂的架构活动中，你作为架构师应该有任务边界划分的全部授权。

我个人就有过类似的经历，需要与多个部门的大佬合作，去进行公司的一个大改造。但我没有获得任何任务边界划分的授权。最后的情形就是，这些大佬的确派了团队来参加架构活动，但是他们所有的代码与设计，一律向各自的部门看齐。

毕竟这个任务自顶向下施压而来的，大佬们并不看好，都想让自己的团队尽快完事儿然后撤出，根本不愿意接受各自团队例行之外的任务。看起来熙熙攘攘一大堆人，其实最后就是把现有的代码搬了个家而已。我后来反思，还不如干脆不组织这个架构活动，让团队开个服务接口算了。

反过来，如果你作为一个架构师，提前有了任务边界划分的授权，那么参与架构活动的人员，都将受你这个架构师的分配。这样一来，要解决的问题就简单很多了。

在有些企业中，每个团队只服务一个用户角色，承接所有来自用户的需求。那么我们这个信条就允许你在架构活动中打破这种边界，从而找到全局更优的架构设计。

举个例子。在实物电商场景中，买家、商家、平台运营者、物流商、人工客服、机器人客服等多个角色，都要查看物流状态。而每个角色的入口应用，如果各自都能调用底层的物流接口，来实现自己的物流状态查询的业务逻辑。那么这个逻辑就会散落到各处，变得很难维护。

但是如果能打破现有的执行域边界，那么你就可以设计并实现一个共享的物流状态查询服务了。

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

任务边界划分有多种方案，这就意味着你必须有一个甄别方案优劣的决策逻辑。这个逻辑决定了你在多个划分方案之间，将会如何打分或者排序。常见的选择是：

1. 最大化项目目标的完成度；
2. 最大化技术方案的结构性；
3. 最小化整体成本；
4. 最大化团队的长期稳定性；
5. 最大化团队的短期稳定性；
6. 最大化决策者或者赞助者的满意度。

在目标确认环节，如果你能把这些工作都做到位了，那么前四项几乎是等价的。

需要注意的是，这六项选择的排序仅仅是我的个人建议，并没有对错之分。如果是在特殊场景下，你可以根据场景需要来进行排序。

比如在缺省的情况下，我建议你将第一个选项作为这个信条的核心部分。那么这个信条的完整表述就是：

信条二：任务边界划分以最大化项目目标的完成度为第一优先级。

哪怕你被决策者明确告知，应该用另外一个选项作为这个信条的一部分，那么第一个选项也可以作为一个约束条件。这时候完整的信条内容就是：

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

之所以建议你这么做，是因为架构师必须持有这个视角：在给定的架构活动目标之下， 要以最大化架构活动的成功来做任务边界划分。

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

架构师经常有做抽象的冲动，导致架构设计中经常会出现不必要的抽象。也就是大家常说的盖楼倾向。

从我的经验来看，在一个高速迭代的互联网业务中，业务探索的方向变化大，模式更迭快，多层架构抽象往往是得不偿失的。而更好的办法则是做阶段性的重构。

多层架构抽象与阶段性重构这两者的区别在于：

1. 前者是在业务模式还没有稳定下来之前做架构抽象。
2. 后者是在业务模式已经稳定且有明确浪费的情况下，然后对重点领域做针对性的重构。这就是重构架构目标之内的抽象。

拿我们上节课提到的电商项目来举例。实物商家和发行商的概念与模型，看起来非常类似，两个角色都是在处理产品、货品和商品之间的关系。

你可能认为中台是个稳赚不赔的事情，所以想做个商家中台，来抽象实物商家和数字发行商。而一旦深入到细节，你会发现细分场景的差异非常大。

• 实物商家的核心需求有入驻、店铺创建、店铺运营、方向调整和退出。而数字发行商的核心需求有签约、内容发布、运营和退出。
• 店铺管理者角色的运营需求有上下架、爆款打造、私域运营、大促、转化分析、进销存管理和售前中后服务等。而数字发行商的运营需求，则是上下架、营销内容创作、粉丝运营、周边生态建设等。

每个需求也会因为运营商和商家的成交量与内容的不同，需要操作的界面也不大相同。 然后你再细化一层，到了最细的商品上下架环节。你会发现上下架的动作，在两个角色中是完全不一样的：

• 对于售卖实物商品的商家来说，上下架的动作是商品详细描述的填写，图片文字和视频的上传，类目的选择和确认，Listing的属性标准的验证，价格和内容的风控审核，以及商品Listing到商品的关系绑定的过程，等等。
• 而对于数字商品，则是数字商品的元数据填写，从第三方获取数字商品的图片和文字信息，信息质量的验证，从供应商指定的文件传输渠道获取源文件，对源文件的编转码和加密，源文件到CDN的分发，等等。

通过这个案例你会发现，很多架构师在不了解细节时就做抽象，那么效率提升最终只能停留在假设阶段。你可能没有意识到，抽象会提升系统的复杂度，自动削弱系统的迭代效率和稳定性。因此，我非常反对没有任何数据支撑和可度量目标驱动的架构抽象。

总的来说，这个信条的核心就是不要在架构活动中制造出新的抽象任务。这个信条的价值就在于简化架构规划的内容，减少执行者的工作量。

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

任务梳理是一个自顶向下的过程，要求我们不能停留在表面的理解上，而要抽取出核心实体，以及针对这些实体的相关操作，并把这些操作隔离出来。

有的人分不太清楚“隔离”和“抽象”，这其实是两个完全不同的概念：

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

我认为抽象这件事情可以后置，等业务稳定了、看清楚了再说。而隔离则不能等，要尽早做。因为隔离后的实体和操作，未来都可以被分别抽象。而对于一个巨石应用来说，就只能做重构了。

比如刚才我们提到的电商案例中，上下架过程中的主要实体有商家、供应商、链接、类目、商品、元数据、源文件等。提到的主要操作有类目选择、属性验证、商品风控、获取文件、编转码、内容加密等。在合适的场景下，这些实体和操作都可以中台化或者FaaS化掉。

到这里，你或许能发现第三和第四条信条是有共通之处的，它们的核心都在于不用过分抽象，但必须要隔离。

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

作为架构师，要明确知道你的引导会对技术和组织边界产生哪些长期的影响。所以在任务边界划分时有一个至关重要的问题，那就是怎么运用康威定律：“设计系统的结构和产生这些设计的组织的沟通结构是同构的”。

你可能觉得还是不要打破现有的组织和沟通边界。只有在边界划分上最大化与现有边界的重叠度，这样才能最小化自己的执行风险。

这个想法有一定的道理。不过，一个大型的架构活动，是企业从旧架构过渡到新架构的最好机会。所以在这个过程中，你可以在一段时间内把不同团队放在同一个办公区，让大家一起做项目，从而最大化组织沟通的连通性。

这种几乎全连通的环境，可以加速你寻找到最优的边界划分。而这种最优边界是面向未来的最优，是能够最小化未来团队间依赖的边界划分策略。因为这是基于用户需求的变化，基于技术趋势、竞争态势和数据模型的演变而得到的。

举个例子。如果财务团队从来没有与平台商家团队有过沟通，意味着这两个系统还没有打通。那么财务团队为企业建设的业财一体化的进销存能力，就不会把平台商家作为一个可能的用户来考虑。与此同时，业财系统也不会被设计成多租户，以撬动商家提升企业的资金效率。

但是如果你把一个商家账务系统交给财务团队去实现，那么你在这两个领域和团队之间就建设了一个沟通渠道，也为面向未来架构的设计埋下了一颗好的种子。在我看来，这才是你作为架构师先知先觉的能力。架构师要想在业务和产品同学之前看到技术为企业创造机会的可能性，这就是一个非常好的契机。这就是为什么我在这节课一开始时就提到了，这可能是你作为架构师，能对长期架构设计产生最大影响的环节了。

不过你可能会好奇，既然这个信条这么重要，为什么还把它排在最末尾呢？难道是优先级不高吗？

原因是这样的。国内互联网行业竞争激烈，资源缺乏，监管环境的变化也非常快。所以面向未来，说起来容易做起来难。加上真正的机会少之又少，所以我不希望让这个信条对你产生误导，让你试图在每一把沙子里找金子。

你在经验不足的时候这么做了，不但不能带来长期突破，反倒会导致更大的浪费。但是等你有了一两个成功案例，对尺度有所心得之后，那么就可以根据企业所处的阶段来调整这个信条的优先级了。

其他信条

这些信条的存在，会让棘手情形转化成集体决策，而不是你个人的决策。而且这些决策，只是暂时在架构活动中生效，不会改变现有的权力格局。因此会提升参与者的接受度，即使有个人或者团队冲突存在。

当然，你也可以试图添加更多的信条。不过总的原则是，在任务边界划分的过程中，从用户需求出发，在架构目标统一的信条下，最终达成切实可行的、从需求到任务到承接关系的划分。这才是边界划分的王道。

如果信条无法在限定时间内完成划分，那也可以采用霸道的方法。请决策者把任务强制部署下去，靠一些额外激励或者惩罚手段来达到目标。在这个阶段，时间非常宝贵，你不能耽误太久。

小结

我们这节课给出了一些信条，以及这些信条背后的思考原则。除了理解这些信条。我建议你这时候再回过头去，重新读一下架构环境建设这节课。结合这节课的内容，来重新理解一下这些信条。目的是除了理解这些信条外，还要进一步去理解制定信条背后的思考，最后试图制定自己的信条。

这也是我在课程开篇词中就讲过的，我写这个课程是想“授人与渔”。

思考题

三个思考题，不过第一题非常重要，是这节课的一部分。

1. 信条是有优先级的。这节课中我故意把前四个信条的顺序打乱了。如果真正使用这些信条的话，我不会按照文章中的顺序来列出。你认为在一个互联网企业中，更合理的顺序会是什么？
2. 如果在这五个信条的基础上再增加一个信条，你会增加什么呢？为什么？如果一定要减少一个信条，你会哪一条呢？为什么？
3. 你做过任务边界划分吗？有了这些信条，你觉得你的划分任务会变得简单吗？为什么？