一、软件架构之架构原则
SOLID 原则是一套比较经典且流行的架构原则：
- 单一职责：与 Unix 哲学所倡导的“Do one thing and do it well”不谋而合；
- 开闭原则：用新增（扩展）来取代修改（破坏现有封装），这与函数式的 immutable 思想也有异曲同工之妙；
- 里式替换：父类能够出现的地方子类一定能够出现，这样它们之间才算是具备继承的“Is-A”关系；
- 接口隔离：不要让一个类依赖另一个类中用不到的接口，简单说就是最小化组件之间的接口依赖和耦合；
- 依赖反转：依赖抽象类与接口，而不是具体实现；让低层次模块依赖高层次模块的稳定抽象，实现解耦。
此外，我们做架构设计时也会尽量遵循如下一些原则：
- 正交性：架构同一层次拆分出的各组件之间，应该尽量保持正交，即彼此职责独立，边界清晰，没有重叠；
- 高内聚：同一组件内部应该是高度内聚的（cohesive），像是一个不可分割的整体（否则就应该拆开）；
- 低耦合：不同组件之间应该尽量减少耦合（coupling），既降低相互的变化影响，也能增强组件可复用性；
- 隔离变化：许多架构原则与模式的本质都是在隔离变化 —— 将预期可能变化的部分都隔离到一块，减少发生变化时受影响（需要修改代码、重新测试或产生故障隐患）的其他稳定部分。
二、架构描述-架构图与架构文档
对于同一件事物，作家会选择用文字来叙述，而画家却会用图画。尽管两者想要传达的信息是一致的，但描述方式的不同也会带来效果上的巨大差异。架构描述也分文字（Text）和图（Diagram）两种形式，两者各有千秋：
- 文字的背后是由一套严谨和完备的语言作为支撑，因此其描述可以做到非常精准和详尽，而且编写起来也很方便，随便打开个记事本软件都能写；此外，就跟写代码一样，文字很易于做版本管理，借助简单的文本 diff 工具就能一目了然地对比出不同版本之间的细节差异；
- 相比而言，图并不具备以上文字所独有的特点，但也有自己的独特优势：图是直观而形象的，顺应了人类与生俱来的视觉识别本能；图的表达能力更强，很多时候一小张图所能传达出的信息（比如空间位置关系、颜色分类、图标形状），也许用一千行字也不足以完整准确地描述出来，即所谓“一图胜千言”。
三、软件架构之5视图理论（1+4 View graph）
系统视图(System view)：描述系统模块组成、环境因素（包括用户、外部系统、标准规范）等等，从整体全局来概括系统。一般通过线框图表示。
逻辑视图(Logical view)：描述系统逻辑结构，描述逻辑模块间的交互依赖关系等等。一般通过线框图表示。
流程视图（Proceess view）：描述系统业务流程、动态交互过程等，一般可通过业务流程图和 UML 中的用例图、时序图、活动图、通信图来表示；
开发视图（Development view）：描述系统开发的类包结构，一般可通过 UML 中的组件图和包图来表示
物理视图（Physical view）：也称为部署视图，描述系统部署结构、硬件环境、网络环境等等，一般可通过 UML 中的部署图来表示。
四、软件架构之C4模型理论（C4 model graph）
系统层：描述系统元外部系统与用户、外部系统的关系与逻辑。
应用层：描述系统内部应用组成、应用描述、应用与应用之间以及应用与外部系统的交互关系。
组件层：描述应用的模块组成、模块描述以及模块间的交互关系。
开发层：描述模块的组成，具体到类与接口，提供方法和属性定义，可直接指导开发。