郭东白的架构课_36_26节点四任务边界划分应该遵循哪些信条
你好，我是郭东白。
上节课呢我们讲了统一语义和需求，确认自呢是架构规划的前两个部分。
自此呢你多数的分区域都应该有一个执行域了。
那么接下来我们就讲讲更细力度的任务边界划分。
上节课呢我们讲到了问题，遇到执行域的映射，这是一个粗力度的映射关系。
不过我们上节课就提到了边界冲突的情况，有些任务是无法在上面的粗力度划分之下完成需求到执行的映射的。
这种粗力度的映射呢有下面三个挑战。
第一呢，我们力度的划分呢是基于现有执行域的这种划分呢，会导致我们的架构设计受执行团队组织结构的约束，也就是坑威定律对架构设计的干扰。
第二呢，无论我怎么努力，依然会在架构活动中碰到执行域划分，没有执行团队和多个执行团队这样的挑战。
第三呢执行域呢是非常粗力度的任务划分，部分有边界冲突的跨领域任务呢需要在更细力度上的任务层面完成执行边界的划分。
那么这节课呢我们聊聊怎么应付这三个挑战。
我们需要把这些需求拆分成研发任务分配给执行者，而这些任务的组合和边界最终会决定长期的基础架构。
这个步骤呢可能是架构师对长期架构设计产生最大影响的一个环节。
所以呢深度理解，从需求到任务承接的关系，以及学会如何分配你的注意力。
是你这节课掌握的一个重要技能。
上节课呢我们讲了四个基础情形，其实是一个架构活动中非常常见的。
你虽然可以升级到决策者解决部分问题，但是假设你按照架构环境搭建这节课里所提建议过的，在团队中建立了架构线条，那么这些基础的情形就相对容易解决很多。
下面呢就是我认为任务边界划分应该具备的信条。
第一，任务边界可以打破现有的执行边界。
我们来区分一下需求和任务。
两个概念。
需求呢是个问题与概念，它来自于用户任务呢是一个执行与概念，它来自于内部的分工合作。
这个信条呢是指任务分配呢指任是该重当前的问题域到执行域的映射。
但是却不需要完全遵照这个映射。
在一个架构活动中，一个架构师更应该从用户思维出发，把任务交给能，最好完成这项任务的团队。
这里特别强调一下，在架构活动中，任务边界的划分是暂时性的，而不是永久性的。
任务边界的划分不同于执行域的划分。
执行域的划分呢是一个组织分工的概念。
每个实体团队在组织中有明确的执行与定位，执行域的划分，关系到管理者和团队的利益，是一个极为敏感的问题的架构是没有权利更改执行域的划分。
之所以强调暂时性，是因为这个任务边界的划分不一定影响长期的组织边界和团队定位。
在这个短暂的架构活动中，你作为架构师根本有任务边界划分的全部授权。
我自己就经历过多个部门大佬们合作任何一个公司大改造的情况，但是我没有任何边界划分的授权，这些大佬们的确派了团队参加架构活动，但是所有的代码和设计一律和自己的部门看齐。
而这个任务呢又是上面派下来的。
大佬们并不看好，想让自己的团队尽快完事撤撤根，根本不愿意接受任何自己团队例行之外的任务，看起来熙攘攘攘，一大堆人。
其实最后就是把现有的代码搬了个家。
我后来反思呢，还不如干脆不组织这个架构活动，我团队开个服务接口就完了。
结果呢是复制了一套，后来几乎完全没办法维护的代码在手上。
反过来呢，如果你作为一个架构师，提前有了任务边界划分的授权，那么参与架构活动中其实是受你支配的这呢会让你解决问题变得简单很多。
尤其是你架构活动涉及多个异构系统合并的情形。
在有些企业中呢，每个团队呢只服务一个用户角色用户，所有需求都由这个团队承接。
那么我们这个信条就允许你在架构活动中打破这种边界，从而找到全局更优的架构设计。
我举个例子啊，在实物电商的场景中，买家、商家、平台、运营者、物流商、人工客服机器人等等多个角色都要查看物流状态。
在每个角色的入口应用，如果各自都能调用底层人的物流接口，来实现自己的物流状态查询业务逻辑的话，那么这个逻辑呢就散落在各处，变得很难维护。
但是如果你打破现有的执行与边界，那你呢就可能设计一个并且实现一个共享的物流状态。
查询服务了线条二任务边界划分有确定的决策优先级任务边界呢可能有多种划分方案。
这就意味着你必须有一个甄别方案，优劣的决策逻辑。
这个逻辑呢决定你在多个划分方案之间如何打分或者排序。
最常见的选择是最大化项目目标的完成度，或者是最大化技术方案的结构性最小化、整体成本最大化团队的长期稳定性，或者是短期稳定性，最大化决策者和专业者赞助者的满意度。
在目标确认环节，如果你能把这些工作都作为呢，那么前四项呢几乎是等价的。
需要注意的是，这六个选择的排序仅仅是我个人建议，其实并没有对错之分。
如果在特殊场景下，你可以根据场景的需要来排序。
缺审的情况下，我建议你选择第一作为这个信条的部分。
那么这个信条的完整表述就变成了线条。
二、任务边界的划分，以最大化项目目标的完成度为第一优先级。
哪怕你被决策者呢明确告知，你应该用另外一个选项作为信条的一部分。
那么第一项也可以作为一个约束条件，这时候可完整的信条可能就是信条。
二、任务边界划分以最小化整体成本为第一优先级，但是不能牺牲项目目标的完成度。
之所以建议你这么做呢，是因为架构师必须持有这个视角在在给定的架构。
活动目标之下，要以最大化架构活动的成功而做任务边界划分线条。
三呢最小化架构目标之外的抽象。
架构师经常呢有做抽象的冲动，很多时候呢我们在架构设计中出现了不必要的抽象。
也就是说大家经常说的盖楼的倾向。
在我的经验来看呢，在一个高速迭代的互联网业务中，业务探索的方向变化大，模式更迭快，多层架构抽象往往是得不偿失的，而更好的办法呢则是做阶段性的重构。
这两者的区别在于，前者呢是根据业务模式还没稳定下来之前做架构抽象。
后者呢是在业务模式已经稳定下来，并且有明确浪费情况下，然后针对重点领域做针对性的重构，这就是重构项目中架构目标之内的抽象。
拿我们上节课提到的电商项目来举例，实物商家和发行商的概念和模型看起来非常类似。
两个角色呢都是在处理产品、货品和商品之间的关系。
你可能认为中台是一个稳赚不赔的事情。
所以想做一个商家中台来抽象实物商家和数字发行商。
但是一旦深入到细节，你会发现细分场景的差异非常大。
实物商家的核心需求有入驻店铺、创建店铺运营方向调整和退出。
而数字发行商的核心诉求有签约内容发布运营会、退出店铺管理者的角色的运营需求有很多，上下架包管打造私域运营、大促转化，分析进销存管理店中售前、售后服务等等等等。
而数字发行商的运营需求则是上下架营销内容，创作、粉丝运营、周边生态建设等等。
每个需求呢也会因为运营商和商家的成交量或者内容不同，需要的操作界面也大不相同。
你然后你要是再细化一层到了最细的商品上下架环节，你会发现上下架动作在两个角色之间完全不一样。
对于售卖实物商品的商家来说，上下架的动作呢就是商品详细描述的填写图片和文字视频的上传类目选择和确认listing属性的必验证价格和内容的风控审核，以及商品listing到商品关系的绑定等等。
而对于数字商品呢，则是数字商品原数据的填写，从第三方获取数字商品的图片和文字信息信息质量的验证。
从供应商指定的文件传输渠道获取原文件，对源文件做编解码和加密，做源文件到CDN的分发等等。
通过这个案例，你会发现很多架构师在不了解细节的时候就做抽象。
那么带来效率提升的假设，最终只能停留在假设阶段。
你可能没意识到，抽象呢会提升系统的复杂度，自动削弱系统的迭代效率和稳定性。
因此，我非常反对没有任何数据支撑和可度量目标驱动的架构。
抽象。
这个信条的核心呢就是不要在架构活动中制造出新的抽象任务。
而价值就在于你简化做架构规划的内容，减少执行者的工作量。
信条四，任务边界划分时要最大化隔离。
任务梳理呢是一个自定向下的过程，要求你不能停留在表面的理解上，需要抽取出核心的实体，以及针对这些实体的相关操作，并且把操作隔离出来。
有人呢分不太清楚，抽象和隔离，其实这是两个完全不同的概念。
隔离呢是把两个实体的相关任务分开来，确保独立分装和实现。
而抽象呢是在两个实体之上，抽象出第三个实体，共享部分任务和实现。
而认为抽象这件事情可以后置等业务稳定，你看清楚了再说。
而隔离则不能等，要尽早做。
因为隔离之后的实体被抽作，未来都可以分别被抽象，而一个句实应用就只能做重构了。
比如说上下架过程提到的主要实体有，商家、供应商、listing类类目、商品原数据、原文件license等等。
提到的主要操作有，类目选择、首性验证商品分工，获取文件编解码内容加解密等等。
在合适的情景下，这些实体和操作都可以中台划掉，或者是fars划掉。
总结一下，第三和第四条的核心就是不必过分抽象，但是必须要隔离。
信条。
五、任务边界的划分要面向未来最优。
作为架构师呢，要知道你的引导会对技术和组织边线产生长期的影响。
所以，在任务边界划分时，有一个至关重要的问题，就是怎么运用康威定律设计系统的结构和产生这些设计的组织和沟通结构是同构的。
你可能觉得还是不要打破现有的组织和沟通边界，在边界化分上最大化和现有边界的重叠度，这样呢才能最小化自己的执行风险。
这个方想法呢其实是有一定道理的。
不过呢在大型架构活动是企业从旧架构到新架构过渡的最好机会。
在这个过程中呢，你可以在一段时间内把不同团队放在同一个办公区内做项目，从而最大化组织的沟通连通性。
这种几乎全联通的环境可以加速你寻找最优的边界划分。
而这种最优边界呢是面向未来的最优，是能够最小化未来团队就不赖的边界划分的一个策略。
这是呢基于用户需求变化、技术趋势竞争态势和数据模型的演变而得到的。
举个例子，如果财务团队从来没有和平常平台商家团队有过沟通，意味着这两个系统还没有打通。
那么财务团队为企业建设的业材一体化的进销存能力，就不会把平台商家作为一个可能的用户来考虑。
业财系统呢也不会被设计成多租户的撬动商家，提升企业的资金效率。
如果你把一个商将账务系统交给财务系统去实现，那么从此呢就在这两个领域和两个团队之间呢建设了一个沟通渠道，也就是你也为面向未来的架构设计埋下的一个很好的种子。
在我看来，这才是你作为架构师先知先觉的能力。
架构师呢要想在业务和产品同学前面看到技术为企业创造机会的可能。
这就是我为什么在课程开始就提到了，这可能是你作为一个架构师能对长期架构设计产生最大影响的环节。
不过呢你可能会好奇，既然这个信条这么重要，为什么我还怕它排在最末？最末尾呢？难道是优先级不够高吗？原因是这样的，国内的互联网行业竞争非常激烈，资源匮乏，监管环境的变化也非常快。
所以面向未来，说起来容易，做起来难，加上真正的机会呢少之又少。
所以我不希望你为这个信条所误导，让你呢试图在每一把沙子里找竞争。
你的经验不足的时候这么做了，不但不能带来长期突破，反而会导致更大的浪费。
但是等你有了一两个成功案例，对尺度有所心得之后，那么就可以根据企业所处的阶段来调整这个信条的优先级了。
其他信条这些信条的存在呢，会让棘手情形转化成集体决策，而不是你的个人决策。
而这些决策只是暂时在架构活动中实你不会改变变现有的权利格局，因此会提升参与者的接受度。
即使有个人或者团队冲突存在，当然呢你也可以试图添加更多的线条。
不过，总的原则是呢在任务边界划分的过程中，从任务需求出发，在架构目标和统一信条的情况下，最终达成切实可行的从需求到任务的承接关系的划分，这才是边界划分的王道。
如果信条没办法在有限时间内完成划分，除了可以采用霸道的方法，请决策者把任务强制部署下去。
靠我们之前提到的额外激励或者惩罚手段来达成目标。
在这个阶段时间非常宝贵，你不能讨论太久，最后给一下小结啊，我们这节课呢给出了一些信条和这些信条背后的思考原则。
除了理解这些信条，我建议你这时候呢再回过头去重新读一下架构环境建设这节课，然后结合课程的内容重新理解一下这些线条，目的是在理解信条之外，进一步理解制定信条背后的思考，然后试图学习自己，去制定信条。
这是我们在课程开篇时候，我就想做的授人以渔的过程，希望你能学习到最后呢是思考题，有三个思考题。
不过第一题呢非常重要是课程的一部分。
信条呢是有优先级的这节课呢，我故意把前四个信条的顺序打乱了。
如果真正使用这些信条的话，我不会按照文章中的顺序来列出为认为在一个互联网企业中更合理的顺序应该是什么？如果你一定要增加一个信条，你会增加一个什么样的信条，为什么呢？如果一定让你减少一个信条，你会减少哪个信条？为什么你做过任务边界划分吗？如果有了这些信条，你觉得任务划分会变得更简单吗？为什么？如果这节课对你有帮助，欢迎你把课程转发给你的同事和朋友，顺便打个广告。
我开了抖音号，欢迎在抖音上搜索郭冬白并关注我们下节课，再见，拜拜。