转载

软件架构概念

“你对架构这个词怎么理解？”

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 呢？

另外，从上面也可以看出，不是只有大系统才有架构，小的模块，小的系统也有架构。因此，在平时编写代码时，即使自己负责的系统很小，也要关心，设计好他的架构。

总结

无论是组成派，还是决策派，在架构设计中，我们都会涉及，只是站的角度不同罢了，前者站在软件的角度，后者站在决策人的角度。例如：当我们决定对模块如何进行划分的时候，这个时候，是决策派。当我们设计模块边界的时候，是组成派。当我们对模块之间的交互接口进行设计的时候，就是组成派。当我们考虑易用性，代码美学，灵活性的时候，是决策派。……

最后，管他什么派，只是角度不同罢了，好的架构，我认为是这样的：模块边界清晰，依赖合理，弹性灵活，性能优越，易于理解。

原文：https://cloud.tencent.com/developer/article/1420598

原文 http://mp.weixin.qq.com/s?__biz=MzA5OTI2MTE3NA==&mid=2658337859&idx=2&sn=6bfbb70b6614a6e528019b8c3c475745

正文到此结束