“你对架构这个词怎么理解？”
emm …..
实际上，软件架构分成 2 派。
1 软件架构的派别
- 组成派 组成派的定义非常简洁。 定义：软件系统的架构将系统描述为计算组件及组件之间的交互。
剖析定义： a. 该架构关注架构实践中的客体——软件，以软件本身为描述对象。 b. 分析了软件的组成，即软件由承担不同任务的组件组成，这些组件通过相关交互，完成更高层次的计算。
- 决策派 决策派的定义相对于组成派的定义，要繁杂很多。但核心思想非常明确：软件架构是在一些重要方面所做出的决策的集合。
定义（软件架构包含了关于以下问题的重要决策）：
- 软件系统的组织
- 选择成为系统的结构元素和他们之间的接口，以及当这些元素相互协作时所体现的行为。
- 如何组合这些元素，使他们逐渐合并成更大的子系统。
- 用于指导这个系统的架构风格：这些元素以及它们的接口、协作和组合。
- 软件架构并不仅仅注重软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制及权衡，以及美学等。
2 组成派、决策派 概念解析
组成派：
架构设计是分与合的艺术。
架构 = 组件 交互。
我们举例 MVC 架构： V 创建 C，C 根据用户交互调用 M 的相关服务，而 M 将自身的改变通知 V，V 通过交互读取 M 的信息以更新自身。
决策派
架构属于设计，但设计不一定属于架构。架构设计的决策，将对整体质量、并行开发、适应变化等方面有着重大影响，例如：
- 模块如何划分
- 每个模块的职责如何
- 每个模块的接口如何定义
- 模块间采用何种交互机制
- 开发技术如何选型
- 如何满足约束和质量属性的需求
- 如何适应可能发生的变化
这里假设我们设计一个 C/S 系统，会有一个决策树：
- 决定采用 C/S 架构，包含 Client 和 Server
- 决定将 Server 分成 3 层
- 决定将 Server 的引擎层划分成 N 个模块
- 决定 …..
可以看出，决策，就是一步步递归，将大任务，通过一个个合理的决策，划分成一个个小任务。是不是类似 fork join 呢？
另外，从上面也可以看出，不是只有大系统才有架构，小的模块，小的系统也有架构。因此，在平时编写代码时，即使自己负责的系统很小，也要关心，设计好他的架构。
总结
无论是组成派，还是决策派，在架构设计中，我们都会涉及，只是站的角度不同罢了，前者站在软件的角度，后者站在决策人的角度。 例如： 当我们决定对模块如何进行划分的时候，这个时候，是决策派。 当我们设计模块边界的时候，是组成派。 当我们对模块之间的交互接口进行设计的时候，就是组成派。 当我们考虑易用性，代码美学，灵活性的时候，是决策派。 ……
最后，管他什么派，只是角度不同罢了，好的架构，我认为是这样的：模块边界清晰，依赖合理，弹性灵活，性能优越，易于理解。
参考
软件架构设计——温昱
