Question

乍一看，“软件架构”似乎很容易定义。它就是讲软件的架构，对吧？没错，但它并不局限于软件。

应用程序架构

对于我们软件开发者来说，最熟悉的应该是应用程序架构，特别是通常由单一技术编写的“应用程序”（比如Java网络应用程序、Windows桌面应用程序，等等）。应用程序架构的关注点是应用程序，通常包括将应用程序解构为类和组件，确保设计模式的正确应用，构建或使用框架，等等。本质上，应用程序架构谈论的是软件设计的低级别切面，通常只考虑单一的技术栈（比如Java、微软.NET等）。

结构单元主要以软件为基础，包括编程语言和结构、类库、框架、API等。它由类、组件、模块、函数、设计模式等加以描述。应用程序架构着重考虑软件和代码组织。

系统架构

我喜欢把系统架构看作是更大规模的应用程序架构。大多数软件系统实际上是由横跨不同层次和技术的多个应用程序组成。举个例子，你可能有这样一个软件系统，Java EE中间层消费Oracle数据库提供的数据，同时向.NET Silverlight客户端提供Web服务。每个部分都有自己的应用程序架构。

要让整个软件系统工作起来，就要思考如何组合这些单独的应用程序。换句话说，要有端到端软件系统在较高层次上的整体结构。另外，大多数软件系统都不是孤立的，因此系统架构还关注互操作性和与环境中其他系统的集成。

结构单元就是各种软硬件，从编程语言和软件框架到服务器和基础设施。跟应用程序架构相比，系统架构描述为从组件和服务到子系统等更高层次的抽象。系统架构的定义大多数都包括了软件和硬件。毕竟，一个成功的软件系统离不开硬件，即使是云上的虚拟硬件。

软件架构

应用程序和系统架构相对较容易理解，但人们对“软件架构”一词的理解不尽相同。我想把软件架构定义得尽可能简单，而不去受制于各种定义的复杂性和细微差别。对我而言，软件结构就是应用程序和系统架构的结合。

换句话说，从代码结构和基础到将代码成功部署到生产环境，与一个软件系统重要元素相关的所有东西就是软件架构。从开发者的角度考虑软件开发，关注点多数会放在代码上。在这里，我们考虑的是有助于构架更好软件的东西，比如面向对象的原则、类、接口、控制反转、重构、自动化单元测试、代码整洁和其他不胜枚举的技术实践。如果你团队里的人都只考虑这些，那么谁来考虑其他事情？

横切关注点，比如登录和异常处理；

安全性，包括认证、授权和敏感数据保密；

性能、可伸缩性、可用性和其他质量属性；

审计及其他监管需求；

客观环境的约束；

互操作性、与其他软件系统的集成；

运营、支持和维护的需求；

结构和整个代码库解决问题、实现特性的方法的一致性；

评估正在构建的基础有助于交付按计划进行。

有时你需要退一步，远离代码和你的开发工具。这并不意味着低层次的细节不重要，因为可用的软件最终还是要靠交付可运行的代码。细节同样重要，但就大局而言，对软件的整体视角可以确保你的代码符合整体愿景而非背道而驰。

企业架构：战略而非代码

企业架构一般是指整个组织的中心工作，着眼于如何组织与利用人员、流程和技术来使企业有效和高效地工作。换句话说，它是关于企业如何分成组或部门，业务流程如何在上层运作，以及技术如何支撑这一切。这跟软件架构形成了强烈对比，因为企业架构没有必要关注技术细节。相反，企业架构可能看重的是如何在整个组织中最好地利用技术，而无需实际介入这些技术的工作原理。

有些开发者和软件架构师把企业架构看作职业发展的下一站，然而大多数人却并非如此。从事企业架构工作所需要的思维方式和软件架构大相径庭，对于技术及其在组织中的应用，视角很不一样。企业架构需要更高层次的抽象。这关乎广度而非深度，关乎战略而非代码。