您现在的位置是：首页 >技术交流 >架构活动中如何做任务边界的划分网站首页技术交流

1、任务边界可以打破现有的执行边界

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

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

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

2、任务边界划分有确定的决策优先级

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

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

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

在给定的架构活动目标之下， 要以最大化架构活动的成功来做任务边界划分。

3、最小化架构目标之外的抽象

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

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

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

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

4、任务边界划分时要最大化隔离

任务梳理是一个自顶向下的过程，要求我们不能停留在表面的理解上，而要抽取出核心实体，以及针对这些实体的相关操作，并把这些操作隔离出来。有的人分不太清楚“隔离”和“抽象”，这其实是两个完全不同的概念：

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

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

5、任务边界划分要面向未来最优

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

一个大型的架构活动，是企业从旧架构过渡到新架构的最好机会。所以在这个过程中，你可以在一段时间内把不同团队放在同一个办公区，让大家一起做项目，从而最大化组织沟通的连通性。这种几乎全连通的环境，可以加速你寻找到最优的边界划分。而这种最优边界是面向未来的最优，是能够最小化未来团队间依赖的边界划分策略。因为这是基于用户需求的变化，基于技术趋势、竞争态势和数据模型的演变而得到的。

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

此文章为5月Day17 学习笔记，内容来源于极客时间《郭东白的架构课》，推荐该课程。