正交设计，什么是正交设计，在之前的几篇文章中，《架构的本质是业务的正交分解》、《应用对变化》都有学习记录。
这两篇文章越看越感觉有道理：
1、系统应该被分解为“最小化核心系统 + 多个彼此正交的周边系统”
2、消除重复
3、分离关注点
4、管理依赖：最小化依赖、向稳定方向依赖
对于这四个策略的理解，感觉自己的认知层次还是太低了。更多的时候还是在作为编码原则。而非架构原则。
在《架构师的自我拯救》提出了技术人员的商业价值，包括两部分：快速试错和快速规模化。
那么我们能在企业的竞争中做些什么，同时也自己创造增量价值呢？其实也被包含在这两方面。
比如快速试错。为什么需要快速试错？为了验证商业想法是否能得到市场认同，从而获得商业价值。必然需要高速响应业务和技术的需求。
这面临的挑战就是交付时间压力。市场不等人，竞争对手也不等人。
除了战略层面的尝试方向对不对，如果有人承诺方向一定对，那自然不用试错，直接火力全开，饱和式攻击就行。
绝大多数情况是没人担保的，只能尝试。对应到技术人员，挑战在于只是很小的一次尝试，不要把系统改得面目全非。
对应到架构，就是我们系统的得符合“开闭原则”。能稳住核心系统的不变性，又能保持系统有序的增量。把大多数的尝试尽量封装到一个小的领域内。不会因为多次的业务尝试，导致系统随着时间变得混乱。
想要做到这些，需要如下架构原则：
1、单一职责，把每个业务尝试封装到一个单一模块中。一旦尝试失败，就可以迅速把业务逻辑下线，避免影响整体的复杂性。
2、最小依赖，整体架构设计要保障大多数业务尝试可以在业务层完成。如果每个业务方的需求都会侵入到底层的逻辑，那么每次尝试都会变成跨模块，甚至跨团队合作，这种架构会大幅降低业务尝试的速度
3、最小暴露，相当于最小被依赖，在业务尝试期接口不对部门或企业外部暴露，包括API、数据共享、事件、消息等一切对外界造成影响的通信机制。尤其是输出，这样才能最小化它的爆炸半径。否则该业务尝试的数据模型会污染到其他业务，在尝试失败之后对其他业务的影响也会很难剥离。
原则很简单，但怎么落地这些原则，最大的挑战来于短视疸。如互联网火热时，人员更替很频繁，导致技术人员的稳定性差，想要快速拿到结果就会设计短视。还有企业组织结构，像康威定律一样，组织间的利益争夺，造成组织内最优设计，但企业整体设计熵增。
作为架构师，可以：
1、提升对封装能力重要性的认知。这是一个技术人员的基本功，从写代码的第一天就需要。只不过随着职业发展，从封装代码架构，到封装业务逻辑，最后到封装业务尝试。
2、建设复杂度控制机制。这里设计评审很关键。业务尝试也要有设计评审，而评审的一个固定环节就是逻辑、数据和接口的最小爆炸半径的设计。
3、推行最小必要架构原则。任何增加功能、引入复杂性的设计，都要做一个正式的评审，而简化的行为则不需要。
当然，这些内容，是在郭东白架构课程里面看到的，他提出这是一个架构师提升企业架构设计对外部的适应能力。我理解这就是应对变化的能力。怎么能更好的应对变化，最佳原则就是“开闭原则”。而这些内容我更感觉是正交设计的另一种表述。这些原则与正交设计是一脉相承的。
如果整个系统的各个功能模块是正交设计的，那自然能灵活应对变化。一个庞大系统无法适应变化时，主要是架构僵化以及各个模块之间的关系错综复杂，导致牵一发而动全身。不能改不敢改。
应对变化时，不要饱和式攻击取胜，需要对阶段性精确目标最大投入取得成果。怎么才能做到不饱和式攻击，在架构层面就是要做到正交分解。
总结一下：架构师主要职责就是为了抵制熵增。而抵制熵增不管从战术还是战略，正交设计都是一种很好的实践方式和指导原则。
