26 节点四：任务边界划分应该遵循哪些信条？
你好，我是郭东白。上节课我们讲了统一语义和需求确认，这是架构规划的前两个环节。至此，多数的问题域都应该有且仅有一个执行域了。那么接下来，我们就来讲更细粒度的任务边界划分，这也是架构规划的第三个环节。
上节课我们讲到了从问题域到执行域的映射，是个粗粒度的映射关系。不过有些任务无法在粗粒度的划分下完成需求到执行的映射，比如我们上节课提到的边界冲突的情况。
总的来说，这种粗粒度的映射会面临三方面的挑战。如下：
- 粒度划分是基于现有执行域的，这种划分导致我们的架构设计会受到执行团队组织结构的约束。也就是康威定律对架构设计的干扰。
- 无论我们怎么努力，依然会在架构活动中碰到执行域划分没有执行团队，或者有多个执行团队的情况。
- 执行域是非常粗粒度的任务划分，但部分有边界冲突的跨领域任务，需要在更细粒度的任务层面上做执行边界的划分。
那么如何应对这三方面的挑战呢？答案是进行任务边界的划分。
我们可以把这些需求拆分成研发任务，并分配给执行者。而这些任务的组合和边界，最终会决定长期的技术架构。因而这个步骤，可能是架构师能对长期架构设计产生最大影响的一个环节了。所以深度理解从需求到任务到承接的关系，以及学会如何分配自己的注意力，就是你这节课要掌握的重要技能。
那么怎么进行任务边界的划分呢？我们前面提到了架构环境建设。从根本上来说，如果能结合架构环境建设，在团队中建立架构信条，那么任务边界的划分就容易得多了。
那么这节课，我们先来讲任务边界划分应该具备的几个信条。下节课我们再来讲具体怎么做任务边界的划分。
信条一：任务边界可以打破现有的执行边界。
我们先来区分一下“需求”和“任务”这两个概念：
- 需求是一个问题域概念，来自用户；
- 任务是一个执行域概念，来自内部的分工合作。
所以这个信条是指，任务分配虽然应当尊重当前问题域到执行域的映射，但却不需要完全遵照这个映射。在一个架构活动中，架构师更应该从用户思维出发，把任务交给能完成这项任务的团队。
这里特别强调一下，在架构活动中，任务边界的划分是暂时性的，不是永久性的。任务边界的划分不同于执行域的划分。执行域的划分是个组织分工概念。每个实体团队在组织架构中有明确的执行域定位。执行域的划分，关系到管理者和团队的利益，是个极为敏感的问题。架构师没有权力更改执行域的划分。
之所以强调暂时性，是因为这个任务边界划分，不一定影响长期的组织边界和团队定位。在这个短暂的架构活动中，你作为架构师应该有任务边界划分的全部授权。
我个人就有过类似的经历，需要与多个部门的大佬合作，去进行公司的一个大改造。但我没有获得任何任务边界划分的授权。最后的情形就是，这些大佬的确派了团队来参加架构活动，但是他们所有的代码与设计，一律向各自的部门看齐。
毕竟这个任务自顶向下施压而来的，大佬们并不看好，都想让自己的团队尽快完事儿然后撤出，根本不愿意接受各自团队例行之外的任务。看起来熙熙攘攘一大堆人，其实最后就是把现有的代码搬了个家而已。我后来反思，还不如干脆不组织这个架构活动，让团队开个服务接口算了。
反过来，如果你作为一个架构师，提前有了任务边界划分的授权，那么参与架构活动的人员，都将受你这个架构师的分配。这样一来，要解决的问题就简单很多了。
在有些企业中，每个团队只服务一个用户角色，承接所有来自用户的需求。那么我们这个信条就允许你在架构活动中打破这种边界，从而找到全局更优的架构设计。
举个例子。在实物电商场景中，买家、商家、平台运营者、物流商、人工客服、机器人客服等多个角色，都要查看物流状态。而每个角色的入口应用，如果各自都能调用底层的物流接口，来实现自己的物流状态查询的业务逻辑。那么这个逻辑就会散落到各处，变得很难维护。
但是如果能打破现有的执行域边界，那么你就可以设计并实现一个共享的物流状态查询服务了。
信条二：任务边界划分有确定的决策优先级
任务边界划分有多种方案，这就意味着你必须有一个甄别方案优劣的决策逻辑。这个逻辑决定了你在多个划分方案之间，将会如何打分或者排序。常见的选择是：
- 最大化项目目标的完成度；
- 最大化技术方案的结构性；
- 最小化整体成本；
- 最大化团队的长期稳定性；
- 最大化团队的短期稳定性；
- 最大化决策者或者赞助者的满意度。
在目标确认环节，如果你能把这些工作都做到位了，那么前四项几乎是等价的。
需要注意的是，这六项选择的排序仅仅是我的个人建议，并没有对错之分。如果是在特殊场景下，你可以根据场景需要来进行排序。
比如在缺省的情况下，我建议你将第一个选项作为这个信条的核心部分。那么这个信条的完整表述就是：
信条二：任务边界划分以最大化项目目标的完成度为第一优先级。
哪怕你被决策者明确告知，应该用另外一个选项作为这个信条的一部分，那么第一个选项也可以作为一个约束条件。这时候完整的信条内容就是：
信条二：任务边界划分以最小化整体成本为第一优先级，但是不能牺牲项目目标的完成度。
之所以建议你这么做，是因为架构师必须持有这个视角：在给定的架构活动目标之下， 要以最大化架构活动的成功来做任务边界划分。
信条三：最小化架构目标之外的抽象
架构师经常有做抽象的冲动，导致架构设计中经常会出现不必要的抽象。也就是大家常说的盖楼倾向。
从我的经验来看，在一个高速迭代的互联网业务中，业务探索的方向变化大，模式更迭快，多层架构抽象往往是得不偿失的。而更好的办法则是做阶段性的重构。
多层架构抽象与阶段性重构这两者的区别在于：
- 前者是在业务模式还没有稳定下来之前做架构抽象。
- 后者是在业务模式已经稳定且有明确浪费的情况下，然后对重点领域做针对性的重构。这就是重构架构目标之内的抽象。
拿我们上节课提到的电商项目来举例。实物商家和发行商的概念与模型，看起来非常类似，两个角色都是在处理产品、货品和商品之间的关系。
你可能认为中台是个稳赚不赔的事情，所以想做个商家中台，来抽象实物商家和数字发行商。而一旦深入到细节，你会发现细分场景的差异非常大。
- 实物商家的核心需求有入驻、店铺创建、店铺运营、方向调整和退出。而数字发行商的核心需求有签约、内容发布、运营和退出。
- 店铺管理者角色的运营需求有上下架、爆款打造、私域运营、大促、转化分析、进销存管理和售前中后服务等。而数字发行商的运营需求，则是上下架、营销内容创作、粉丝运营、周边生态建设等。
每个需求也会因为运营商和商家的成交量与内容的不同，需要操作的界面也不大相同。 然后你再细化一层，到了最细的商品上下架环节。你会发现上下架的动作，在两个角色中是完全不一样的：
- 对于售卖实物商品的商家来说，上下架的动作是商品详细描述的填写，图片文字和视频的上传，类目的选择和确认，Listing的属性标准的验证，价格和内容的风控审核，以及商品Listing到商品的关系绑定的过程，等等。
- 而对于数字商品，则是数字商品的元数据填写，从第三方获取数字商品的图片和文字信息，信息质量的验证，从供应商指定的文件传输渠道获取源文件，对源文件的编转码和加密，源文件到CDN的分发，等等。
通过这个案例你会发现，很多架构师在不了解细节时就做抽象，那么效率提升最终只能停留在假设阶段。你可能没有意识到，抽象会提升系统的复杂度，自动削弱系统的迭代效率和稳定性。因此，我非常反对没有任何数据支撑和可度量目标驱动的架构抽象。
总的来说，这个信条的核心就是不要在架构活动中制造出新的抽象任务。这个信条的价值就在于简化架构规划的内容，减少执行者的工作量。
信条四：任务边界划分时要最大化隔离
任务梳理是一个自顶向下的过程，要求我们不能停留在表面的理解上，而要抽取出核心实体，以及针对这些实体的相关操作，并把这些操作隔离出来。
有的人分不太清楚“隔离”和“抽象”，这其实是两个完全不同的概念：
- 隔离是把两个实体的相关的任务分开来，确保独立封装和实现。
- 而抽象是在两个实体之上抽象出第三个实体，共享部分任务和实现。
我认为抽象这件事情可以后置，等业务稳定了、看清楚了再说。而隔离则不能等，要尽早做。因为隔离后的实体和操作，未来都可以被分别抽象。而对于一个巨石应用来说，就只能做重构了。
比如刚才我们提到的电商案例中，上下架过程中的主要实体有商家、供应商、链接、类目、商品、元数据、源文件等。提到的主要操作有类目选择、属性验证、商品风控、获取文件、编转码、内容加密等。在合适的场景下，这些实体和操作都可以中台化或者FaaS化掉。
到这里，你或许能发现第三和第四条信条是有共通之处的，它们的核心都在于不用过分抽象，但必须要隔离。
信条五：任务边界划分要面向未来最优
作为架构师，要明确知道你的引导会对技术和组织边界产生哪些长期的影响。所以在任务边界划分时有一个至关重要的问题，那就是怎么运用康威定律：“设计系统的结构和产生这些设计的组织的沟通结构是同构的”。
你可能觉得还是不要打破现有的组织和沟通边界。只有在边界划分上最大化与现有边界的重叠度，这样才能最小化自己的执行风险。
这个想法有一定的道理。不过，一个大型的架构活动，是企业从旧架构过渡到新架构的最好机会。所以在这个过程中，你可以在一段时间内把不同团队放在同一个办公区，让大家一起做项目，从而最大化组织沟通的连通性。
这种几乎全连通的环境，可以加速你寻找到最优的边界划分。而这种最优边界是面向未来的最优，是能够最小化未来团队间依赖的边界划分策略。因为这是基于用户需求的变化，基于技术趋势、竞争态势和数据模型的演变而得到的。
举个例子。如果财务团队从来没有与平台商家团队有过沟通，意味着这两个系统还没有打通。那么财务团队为企业建设的业财一体化的进销存能力，就不会把平台商家作为一个可能的用户来考虑。与此同时，业财系统也不会被设计成多租户，以撬动商家提升企业的资金效率。
但是如果你把一个商家账务系统交给财务团队去实现，那么你在这两个领域和团队之间就建设了一个沟通渠道，也为面向未来架构的设计埋下了一颗好的种子。在我看来，这才是你作为架构师先知先觉的能力。架构师要想在业务和产品同学之前看到技术为企业创造机会的可能性，这就是一个非常好的契机。这就是为什么我在这节课一开始时就提到了，这可能是你作为架构师，能对长期架构设计产生最大影响的环节了。
不过你可能会好奇，既然这个信条这么重要，为什么还把它排在最末尾呢？难道是优先级不高吗？
原因是这样的。国内互联网行业竞争激烈，资源缺乏，监管环境的变化也非常快。所以面向未来，说起来容易做起来难。加上真正的机会少之又少，所以我不希望让这个信条对你产生误导，让你试图在每一把沙子里找金子。
你在经验不足的时候这么做了，不但不能带来长期突破，反倒会导致更大的浪费。但是等你有了一两个成功案例，对尺度有所心得之后，那么就可以根据企业所处的阶段来调整这个信条的优先级了。
其他信条
这些信条的存在，会让棘手情形转化成集体决策，而不是你个人的决策。而且这些决策，只是暂时在架构活动中生效，不会改变现有的权力格局。因此会提升参与者的接受度，即使有个人或者团队冲突存在。
当然，你也可以试图添加更多的信条。不过总的原则是，在任务边界划分的过程中，从用户需求出发，在架构目标统一的信条下，最终达成切实可行的、从需求到任务到承接关系的划分。这才是边界划分的王道。
如果信条无法在限定时间内完成划分，那也可以采用霸道的方法。请决策者把任务强制部署下去，靠一些额外激励或者惩罚手段来达到目标。在这个阶段，时间非常宝贵，你不能耽误太久。
小结
我们这节课给出了一些信条，以及这些信条背后的思考原则。除了理解这些信条。我建议你这时候再回过头去，重新读一下架构环境建设这节课。结合这节课的内容，来重新理解一下这些信条。目的是除了理解这些信条外，还要进一步去理解制定信条背后的思考，最后试图制定自己的信条。
这也是我在课程开篇词中就讲过的，我写这个课程是想“授人与渔”。
思考题
三个思考题，不过第一题非常重要，是这节课的一部分。
- 信条是有优先级的。这节课中我故意把前四个信条的顺序打乱了。如果真正使用这些信条的话，我不会按照文章中的顺序来列出。你认为在一个互联网企业中，更合理的顺序会是什么？
- 如果在这五个信条的基础上再增加一个信条，你会增加什么呢？为什么？如果一定要减少一个信条，你会哪一条呢？为什么？
- 你做过任务边界划分吗？有了这些信条，你觉得你的划分任务会变得简单吗？为什么？
如果这节课对你有帮助，欢迎你把课程转发给你的同事或朋友。顺便打个小广告，我刚开了个人抖音号，我会定期发表一些比较新、但是不一定那么成熟的观点。欢迎在抖音上搜索“郭东白”并关注，也欢迎你的批评指正。我们下节课再见！
- 李二木 👍（9） 💬（1）
说一个最近在团队内部任务划分的坑。当时任务划分不够细粒度，可以理解为稍微有点抽象，任务划分时没有异议，但是等到找对方要接口时，双方就开始各抒己见说是该功能点是对方的。事后反思了下。还是任务划分不够细致。任务应该要划分到不可分割，然后指定责任人。免得事后扯皮。
2022-03-29 - 预测师 👍（2） 💬（1）
郭老师，信条和原则的区别是什么，那么多指导架构的名词，如何理解其抽象层次？
2022-05-03 - ACK 👍（1） 💬（1）
1. 信条二：任务边界划分有确定的决策优先级。 2. 信条四：任务边界划分时要最大化隔离。 3. 信条一：任务边界可以打破现有的执行边界。 4. 信条三：最小化架构目标之外的抽象。 完成大于完美，完成是 1，完美和隔离，打破边界是后面的 0. 没有 1，后面的 0 也没意义了。
2022-11-15 - 术子米德 👍（1） 💬（2）
🤔☕️🤔☕️🤔 * 📖：需求转化为任务，实现从问题域到执行域的映射。如果遇到粒度划分问题的挑战，解决之道是进行任务边界的划分。这几个信条该具备：可打破现有执行边界、有确定的决策优先级、最小化架构目标之外的抽象、最大化隔离、面向未来最优。 * 🤔：这个需求大家是否都清楚，跟这个需求是否大家都认可，这中间可能是个巨大的裂缝。我自己的经验，这个裂缝里刚开始可能只有空气，后面会有水灌进去，最终会变成酱缸。产生这样的情况，一方面可能来自历史的缘故，导致各种不信任，另一方面更可能是利益无关或利益冲突。这些问题，看似非技术问题，是否可以通过架构来解决，或者架构能对此改善？以我现在的认知，如果此时的架构，仅指技术架构，这顶多解决在如何，即How层面做到最优。如果把组织架构和业务架构放进来，前者，组织架构去解决我们是什么，即What层面认清自己到底要什么，后者，业务架构去解决我们如何能赚钱，即Why层面认清为何能赚到当下和未来的钱。前提条件，那就是大家都能有这样的共识，或者，大家都认可某人的领导力，由他来带领大家跨过裂缝，这样就有机会打破现有的执行边界。只要执行边界能打破，后面的共识建立起来，就是大家都坐在圆桌上讨论，而不再是在每个峡谷对面呼喊，还假装没听到的样子。 * 🤔：增加信条：“粒度划分越难的地方，越可能是最有潜力的地方”，所谓的越难过越得过。某个点的粒度难划分，可能是这个点本身我们不熟悉，这次下来弄明白，我们的能力就增长，还可能是我们的组织结构不合理，这次行动下来，可以优化组织。 * 🤔：去掉抽象，不会妨碍太多，过渡关注抽象，反而绊手绊脚。如果一个业务持续有发展，持续有新需求和变化，那么在这个过程里去抽象还来得及。最担心的就是，刚开始抽象得特别完美，然后就没有然后。
2022-04-04 - 罗均 👍（1） 💬（1）
东白老师的课程实在太精彩了！学生没有在互联网行业待过，从传统制造业的经验看，四个信条的顺序应该是： 1. 信条四：任务边界划分时要最大化隔离。 2. 信条二：任务边界划分有确定的决策优先级。 3. 信条一：任务边界可以打破现有的执行边界。 4. 信条三：最小化架构目标之外的抽象。 关于老师总结的五个信条，学生反复思量，也无法对此增加或减少。期待有大神与老师碰出思想的火花。 在实践过程中，学生觉得隔离和决策优先级最重要。没有清晰的隔离分析，就很难做判断决策的优先级。
2022-03-30 - 潜水的鲸 👍（0） 💬（1）
2、4、3、1 线确定目标和优先级，然后做重点隔离和影响隔离，加少不必要的工作降低工作的复杂度，最后打破组织结构。最后一项是最困难的，有很多执行层面之外的阻力。不是有很大收益和关键性作用，不要触碰。
2022-06-10 - ， 👍（0） 💬（1）
老师的这几个信条,在我看来是从不同的角度出发考虑的问题。 譬如 信条一,任务边界可以打破现有的执行边界,这条是从项目经理跟产品经理的角度出发,对开发任务的合理划分和分配; 信条二,任务边界划分有确定的决策优先级,是从CTO的角度出发,遵循之前定下的架构目标; 信条三,最小化架构目标之外的抽象;信条四,任务边界划分时要最大化隔离;信条五：任务边界划分要面向未来最优,则与Robert C. Martin在<<架构整洁之道>>里提出的SOLID架构原则暗合。其实就是我们老生常谈的架构师,从产出合理的解决方案的视角出发得到的结论,做架构要符合单一职责(一套代码面向一类人的需求)和接口隔离(面向不同人群需求的代码需要彻底隔离开),依赖倒置等原则(为未来留出抽象空间)。 如果从这个角度来看,思考题1说的是,研发资源有限性,架构目标合理性跟解决方案合理性之间取舍,三者并不是有你就没有我的关系,而是你中有我,我中有你的关系,因此三者不应该是稳定不变的状态,而是不停地在变,有一个动态平衡的过程,资源紧缺那就先优先级高的事情,感觉目标不合理了,不断地纠正目标,解决方案则一定要按照架构原则,围绕着架构目标来做,不然的话即便短期有收益,长远来看还是会给系统留下坏味道。
2022-05-13 - 小兵 👍（0） 💬（1）
小小杠一下，按照这个信条，在落地执行层面还需要思考很多。有没有那种更具备执行信性的方法论，来指导我们划分各个边界。当然事实上我在其他书也没看到非常清晰的方法论，所以最后还是更多基于对业务的认知逐步修正
2022-04-20 - spark 👍（0） 💬（2）
郭老师，take away~~~做不好这件事情的“阻力”：2个重点，思维方式的完整性、格局见识。1个能力，抽象能力~~~逆向思维，不具备这些能力一定做不好这个工作，我有一个领导，总是纠结边界划分和抽象的层次，把我“恶心”离职。1万小时技术，积累不超过5000小时的技术，就做不好这个事情，需要成为半个专家才行~~~
2022-03-29 - BIZ_UI_3 👍（0） 💬（0）
“信条一：任务边界可以打破现有的执行边界。” —— 这是否意味着某种团队职责不明确的情况？是否需要执行反康威定律的工作。。。
2022-03-29 - 本一 👍（4） 💬（1）
如果是我，应该是按2 4 1 3这样，先规划决策优先级的原则，然后做内聚性设计，再考虑打破现有组织结构，然后考虑是不是过度设计的问题
2022-04-01 - james.d 👍（0） 💬（0）
“很多架构师在不了解细节时就做抽象，那么效率提升最终只能停留在假设阶段”，这个观点太正确了，尤其是在大公司，身边不少TL、架构师说到业务系统建设，一定会说平台化/中台化，甚至是在系统建设初期。 抽象一定是建立在具象上面的，了解的细节越多&&业务越稳定，抽象的东西越靠谱；不稳定的抽象简直就是开发者的灾难，过于抽象的东西对架构/开发毫无价值；要做好抽象一定要把手弄“脏”，亲自下场去了解业务的现状和未来。
2023-11-30 - 亚林 👍（0） 💬（0）
很多架构师在不了解细节时就做抽象，那么效率提升最终只能停留在假设阶段。你可能没有意识到，抽象会提升系统的复杂度，自动削弱系统的迭代效率和稳定性。因此，我非常反对没有任何数据支撑和可度量目标驱动的架构抽象。 这个经常遇到。
2022-07-28 - Steven 👍（0） 💬（0）
问题1，我觉得是要区分产品阶段的： 如果是启动和成长阶段，则二、四、三、一。 如果成长阶段中后期到成熟阶段，信条一的优先级要提高了，可以二、一、四、三。
2022-03-30 - 陈桐 👍（0） 💬（0）
讲得太好了，郭老师，已经拜读完，及时更新😀
2022-03-29