从架构设计的角度来说，我们要把大多数的尝试尽量封装到一个小的领域内。这个时候，多次的业务尝试不会随着时间而导致混乱，削减技术体系的外部适应性。做到这点，下面的这些架构原则非常重要。
第一，单一职责，指的是要把每个业务尝试尽量封装到一个单一模块中。好处是一旦尝试失败，就可以迅速把业务逻辑下线，避免影响整体的复杂性。
业务尝试在 90% 的情况下，都是不符合预期的。在这种情况下，符合单一职责的设计很容易下线旧逻辑。这么做很重要，你接手一个烂摊子的时候，肯定恨死那些不下线无效逻辑的前辈们了。打个比方：不下线失效逻辑，就是一个不冲厕所的行为！
第二，最小依赖，指的是整体架构设计要保障大多数业务尝试可以在业务层完成。如果每个业务方的需求都会侵入到底层的逻辑，那么每次尝试都会变成跨团队合作，这种架构会大幅降低业务尝试的速度。
第三，最小数据共享。一个正在尝试中的业务应该尽量减少与其他业务模块的数据交换，尤其是输出，这样才能最小化它的爆炸半径。否则该业务尝试的数据模型会污染到其他业务，在尝试失败之后对其他业务的影响也会很难剥离。
第四，最小暴露，指的是在业务尝试期接口不对部门或企业外部暴露，包括 API、数据共享、事件、消息流等一切对外界造成影响的通信机制。
战略级项目应该在全公司层面明示，而且要维持足够长的时间。
大多数时候，保护技术体系长期的外部适应性和实现当下的需求一样重要，如果不是更重要的话。
当然，还提到技术岗供给压力导致技术人员的稳定性差和设计短视的问题。想减少这种问题，你作为架构师可以：
第一，提升对封装能力重要性的认知。你要帮每个做技术的同学认识到：我们都要有有效封装业务尝试的能力，这个能力最终会转化为提升技术的外部适应性的能力。这是一个技术人员的基本功，从你写代码的第一天就需要。只不过随着你的职业发展，你从封装代码逻辑，到了封装业务逻辑，最后到了封装业务尝试。一个程序员在日常工作中忽略这方面的能力训练，其实是个不明智的选择。
第二，建设复杂度控制机制。在这里，设计评审很关键。业务尝试也要有设计评审，而评审的一个固定环节就是逻辑、数据和接口的最小爆炸半径的设计。
第三，推行最小必要架构原则。在公司范围内推行奥卡姆剃刀（Occam’s Razor）原则。任何增加功能、引入复杂性的设计，都要做一个正式的评审，而简化的行为则不需要。
一个架构师要拥有的业务理解的能力，是基于自己对业务深度认知之后的技术洞察，然后通过这个技术洞察来推动业务发展的能力。