架构解决的核心问题是在代码规模、人员规模扩大以后依然能够保持高效协作，不至于出现1+1<2的困境。

解决的办法通常是制定规范，约束行为，来提升协作效率。整个计算机的发展史都蕴含了这样的思维，例如计算机网络7层设计等。

架构思维反映在软件工程的方方面面，大致涵盖这几个维度：

. 编程范式

. 代码设计

. 组件构建

. 软件架构

编程范式

不同的编程范式(过程式、面向对象、函数式)都是通过对编程模式的约束，实现更有效率的代码协作与管理。

• 过程式编程的核心是禁止使用goto语句，通过限制程序员对代码的直接控制权，大大提升了程序的可读性和可维护性
• 面向对象编程的核心是多态性，我们可以通过定义统一的接口（如C++的基类）实现在不影响核心代码的前提下以插件的形式快速扩展程序功能
• 函数式编程则是通过限制变量修改，实现模块的无状态化（例如云计算中的无服务）从而提升可维护性和横向扩展能力

代码设计

以上编程范式的设计内在理念都构成了如今普遍实践中的架构设计哲学：SOLID

• SRP单一职责原则：每一个模块应该只负责一类行为或者职责，避免过度耦合
• OCP开闭原则：新增功能时应当最小化修改原有代码，实现插件式扩展
• LSP里氏替换原则：类的继承需要确保子类能够正常实现基类所有接口，否则就不应当继承，或者重新设计基类
• ISP接口隔离原则：任何模块都不要依赖他不需要的模块功能，带来不必要的运维复杂度
• DIP 依赖反转选择：代码中抽象接口和具体实现之间需要明确边界，抽象接口被精心设计稳定不变，具体实现只依赖和调用抽象接口，代码依赖和控制流反向

组件构建原则

组件级别我们需要关注两组原则：组件设计原则与组件耦合选择

组件设计原则，回答哪些组件应该放在一起，包括：

• REP复用／发布等同选择：同一个组件中的模块因为紧密相关，应该共享版本号并被一起发布
• CCP共同闭包选择：同一个组件中的内容经常需要一起变更，SRP的组件版
• CRP共同复用原则：同一个组件中的内容经常需要被一起使用或引用，ISP原则的普适版

REP 和 CCP倾向于让组件变得更大，而CRP 倾向于让组件变小变紧凑

软件架构

软件级别需要考虑的问题包括：开发，部署，运行，维护

• 开发方面，架构设计应该与团队结构一致，每个团队负责一个模块
• 部署方面，架构应当带来尽可能简化的部署，甚至一键部署。大量的微服务就是一个反面例子
• 运行方面，虽然架构会影响性能，但硬件成本一般低于人力，因此很少为此优化。但架构需要保证简易的运行监控，方便诊断运行时故障
• 维护方面，架构应当提供充分的灵活性给未来的新功能，最小化系统变更对现有系统的影响

此外，最重要的原则是：保持可选项。即在非核心组建的具体细节上尽可能推迟决定，保持架构随时变更的灵活性

灵活的软件架构应当能够应对任何未来变化，具体做法是将架构拆分为策略和细节两层：

策略层定义抽象的业务逻辑和协作约定，细节层决定具体实现。例如策略层决定使用一个数据库，但不必决定到底是sql server还是PostgreSQL，这些留给细节层决定。且确保任何时候，我们都能轻松的在细节层更换实施方案而不影响策略层的设计

抽象策略需要按照业务逻辑分层解耦，例如一个web应用会解耦成前端、后端、数据库，而这里每个层次又可以继续拆分为子层。

具体的设计可以参考「简洁架构」：以核心业务逻辑和实体为中心，让非业务模块(数据库，UI, 接口，设备，框架)以插件的形式接入系统，并通过网关或者控制器来解耦和对接不同插件的具体实现

这样的目的是确保核心业务策略不依赖任何具体实现，从而达到业务逻辑的独立维护，以及系统插件的灵活替换