什么是系统架构？

什么才是“软件架构”呢？软件架构师的工作内容究竟是什么？这项工作又是什么时候进行的呢？

软件架构师自身需要是程序员，并且必须一直坚持做一线程序员，绝对不要听从那些说应该让软件架构师从代码中解放出来以专心解决高阶问题的伪建议。

软件架构师其实应该是能力最强的一群程序员，他们通常会在自身承接编程任务的同时，逐渐引导整个团队向一个能够最大化生产力的系统设计方向前进。也许软件架构师生产的代码量不是最多的，但是他们呢必须不停的承接编程任务。

如果不亲自承受因系统设计而带来的麻烦，就体会不到设计不佳所带来的痛苦，接着就会逐渐迷失正确的设计方向。

软件系统的架构质量是由它的构建者所决定的，软件架构这项工作的实质就是规划如何将系统拆分成组件，并安排好组件之间的排列关系，以及组件之间互相通信的方式。

软件架构的终极目标就是最大化程序员的生产力，同时最小化系统的总运营成本。

所有的软件系统都可以降解为策略与细节这两种元素。策略体现的是软件中所有的业务规划和操作过程，因此它是系统真正的价值所在。

优秀的架构师会小心地将软件的高层策略与其底层实现隔离开，让高层策略与实现细节脱钩，使其策略部分完全不需要关心底层细节，当然也不会对这些细节有任何形式的依赖。

一、独立性

一个设计良好的架构应该能允许一个系统从单体结构开始，以单一文件的形式部署，然后逐渐成长为一组相互独立的可部署但愿，甚至是独立的服务或者微服务。最后还能够随着情况的变化，允许系统逐渐回退到单体结构。

二、划分边界

软件架构设计本身就是一门划分边界的艺术。边界的作用是将软件分割成各种元素，以便约束边界两侧之间的依赖关系。其中有一些边界是在项目初期——甚至在编写代码之前——就已经划分好，而其他的边界则是后来才划分的。在项目初期划分这些边界的目的是方便我们尽量将一些决策延后进行，并且确保未来这些决策不会对系统的核心业务逻辑产生干扰。

正如我们之前所说，架构师们应该追求的目标是最大限度地降低构建和维护一个系统所需的人力资源。那么我们就需要了解一个系统最消耗人力资源的是什么？答案是系统中存在的耦合——尤其是那些过早做出的、不成熟的决策所导致的耦合。

那么，怎样的决策会被认为是过早且不成熟的呢？答案是那些决策与系统的业务需求无关。

三、边界剖析

所谓划分边界，就是指在这些模块之间建立这种针对变更的防火墙。

系统架构中最强的边界形式就是服务。

四、策略与层次

本质上，所有的软件系统都是一组策略语言的集合。软件架构设计的工作重点之一就是，将这些策略彼此隔离，然后将它们按照变更的方向进行重新分组。其中变更原因、时间和层次相同的策略应该被分到同一个组件中。分之，变更原因、时间和层次不同的策略则应该分属于不同的组件。

软件设计的工作常常需要将组件重排组合成为一个有向无环图。一般来说，低层组件被设计为依赖于高层组件。

五、业务逻辑

业务逻辑是一个软件系统存在的意义，它们属于核心功能，是系统用来赚钱火省钱的那部门代码，是整个系统的皇冠明珠。

这些业务逻辑应该保持纯净，不要掺杂用户界面或者所使用的数据库相关的东西。在理想情况下，这部门代表业务逻辑的代码应该是整个系统的核心，其他底层概念的实现应该以插件的形式借入系统中。业务逻辑应该是系统中最独立、复用性最高的代码。

六、尖叫的软件架构

Jacobson：软件的系统架构应该为该系统的用例提供支持。这就像住宅和图书馆的建筑计划满篇都在非常明显地凸显这些建筑的用例一样，软件系统的架构设计图也应该非常明确地凸显该应用程序会有那些用例。

架构设计的核心目标

一个良好的架构设计应该围绕着用例来展开的，这样的架构设计可以在脱离框架、工具以及使用环境的情况下完整地描述用例。这就好像一个住宅建筑设计的首要目标应该是满足住宅的使用需求，而不是确保一定要用砖来构建整个房子。

而且，良好的架构设计应该尽可能地允许用户推迟和延后决定采用什么框架、数据库、Web 服务以及其他与环境相关的工具。

同时，良好的架构设计还应该让我们很容易改变这些决定。

框架是工具而不是生活信条

一个系统的架构应该着重于展示系统本身的设计，而并非该系统所使用的框架。