信条一：任务边界可以打破现有的执行边界。
任务分配虽然应当尊重当前问题域到执行域的映射，但却不需要完全遵照这个映射。在一个架构活动中，架构师更应该从用户思维出发，把任务交给能完成这项任务的团队。
在架构活动中，任务边界的划分是暂时性的，不是永久性的。
信条二：任务边界划分有确定的决策优先级
常见的选择是：
- 最大化项目目标的完成度；
- 最大化技术方案的结构性；
- 最小化整体成本；
- 最大化团队的长期稳定性；
- 最大化团队的短期稳定性；
- 最大化决策者或者赞助者的满意度。
在给定的架构活动目标之下， 要以最大化架构活动的成功来做任务边界划分。
信条三：最小化架构目标之外的抽象
在一个高速迭代的互联网业务中，业务探索的方向变化大，模式更迭快，多层架构抽象往往是得不偿失的。而更好的办法则是做阶段性的重构。
很多架构师在不了解细节时就做抽象，那么效率提升最终只能停留在假设阶段。你可能没有意识到，抽象会提升系统的复杂度，自动削弱系统的迭代效率和稳定性。因此，我非常反对没有任何数据支撑和可度量目标驱动的架构抽象。
这个信条的核心就是不要在架构活动中制造出新的抽象任务。这个信条的价值就在于简化架构规划的内容，减少执行者的工作量。
信条四：任务边界划分时要最大化隔离
隔离则不能等，要尽早做。因为隔离后的实体和操作，未来都可以被分别抽象。而对于一个巨石应用来说，就只能做重构了。
第三和第四条信条是有共通之处的，它们的核心都在于不用过分抽象，但必须要隔离。
信条五：任务边界划分要面向未来最优
只有在边界划分上最大化与现有边界的重叠度，这样才能最小化自己的执行风险。
全连通的环境，可以加速你寻找到最优的边界划分。而这种最优边界是面向未来的最优，是能够最小化未来团队间依赖的边界划分策略。因为这是基于用户需求的变化，基于技术趋势、竞争态势和数据模型的演变而得到的。
这可能是你作为架构师，能对长期架构设计产生最大影响的环节了。
其他信条
当然，你也可以试图添加更多的信条。不过总的原则是，在任务边界划分的过程中，从用户需求出发，在架构目标统一的信条下，最终达成切实可行的、从需求到任务到承接关系的划分。这才是边界划分的王道。
此文章为5月Day27学习笔记，内容来源于极客时间《郭东白的架构课》
