做架构到底是做什么？

在《首席架构师的打怪升级之路
》中提到：架构师是具备架构能力的人，架构能力是指为相对复杂的场景设计并引导一个或多个研发团队，来实施结构化软件系统的能力。

关键信息：复杂场景结构化

在《软件设计之美》中总结了软件复杂性来自业务复杂性和技术复杂性。应对的办法是通过分而治之，控制规模大小；保持结构清晰与一致性来降低认知负荷。并且要有一定的前瞻性，拥有可扩展性，能应对变化。

关键信息：规模可控、结构清晰、应对变化

总结以上两篇的关键信息：做架构就是通过规模可控、结构清晰的小模块去组合成大模块，进而形成更复杂的软件系统。并且拥有足够的扩展性应对未来的变化。

架构的核心就是【组合与应对变化】；简洁点，三个字：“分、合、变”。

这些其实与“业务的正交分解”方法是一脉相承的。

正交分解

既然是业务的正交分解，自然得理解正交是什么意思？

在《应对变化》详细介绍过正交设计。

简而言之，主要是三个要点：

1、消除重复

2、分离关注点

3、管理依赖：缩小依赖的范围和向稳定的方向依赖

想要把一个复杂的系统拆解成一个一个可被理解掌控、并且又能被结构化地合并成大模块的小模块。正交设计是必须的。

这考验了架构的拆解能力，拆解的合理性就是解耦的合理性；并能在合并时每一个模块保持高内聚。

正交设计主要应对的是“分、合”，那么怎么应对“变”？

就得提到著名的开闭原则。开闭原则是架构治理的根本哲学。

之前也整理了下OCP原则，《SOLID之OCP》，只要我们面向接口编程，就能大概率的符合开闭原则。当时的理解回头看还是比较肤浅的。

一些人对开闭原则的错误解读，认为开闭原则不鼓励修改软件的代码来响应新需求。这显然比较极端。

一个软件产品只要在其生命周期内，就会不断发生变化。变化是一个事实，需要让软件去适应变化。我们应该在设计时尽量适应这些变化，以提高项目的稳定性和灵活性，真正实现“拥抱变化”。

其实，开闭原则的背后，是推崇模块业务的确定性。可以修改模块代码的缺陷，但不要去随意调整模块的业务范畴，增加功能或减小功能都不鼓励。这意味着模块的业务变更是需要极其谨慎的，需要经得起推敲的。

开闭原则指出尽量通过扩展软件实体的行为来应对变化，满足新的需求，而不是通过修改现有代码来完成变化，它是为软件实体的未来事件而制定的对现行开发设计进行约束的一个原则。

总结一下，开闭原则就两点：

1、模块的业务要稳定。当要修改模块业务时，不如实现一个新业务模块。而实现一个新的业务模块来完成新的业务范畴，是一件轻松的事。这个角度，鼓励写“只读”的业务模块，一经设计不可修改。需要变化不如把它归档，放弃掉。这种模块业务只读的思想，是架构治理的基础哲学。

2、模块的业务变化点，简单一点，通过回调函数或者接口开放出去，交给其他业务模块。复杂一点，通过引入插件机制把系统分解为“最小化的核心系统+多个彼此正交的周边系统”。

将开闭原则应用到业务系统。业务对外只读，意味着不可变，但不变的业务生命周期是很短暂的，所以要可扩展。要扩展还要不变，就你倒逼着要做兼容，而兼容可能导致现有的功能职责不单一，这又倒逼着要对现有的功能做再抽象，以适应更广的“单一职责”。

所以不改是不可能的，只是改的结果应当是让项目往更稳定方向发展，而这很难。无论是新的抽象还是职责范围的扩张，需要强大的分析能力和精湛的设计。

这种不变与变其实也印证了架构第一定律：一切都是权衡