软件架构的定义与问题

软件架构（software archiecture）也称之为软件体系结构，它是一组有关如下要素的重要
决策：软件系统的组织，构成系统的结构化元素，接口和它们相互协作的行为的选择，结构
化元素和行为元素组合成粒度更大的子系统的方式的选择，以及指导这一组织（元素及其接
口、协作和组合方式）的架构风格的选择。
软件架构是对系统整体结构设计的刻划，一直以来，对于架构的理解有两个基本概念，
一个称之为组成，另一个称之为决策。
组成：架构的组成概念强调“计算机及组件之间的交互”。例如在的初步设计中，“表
示层”和“业务层”是两个粗粒度的黑盒，当内部也表达了一些粒度比较细的组件
的时候，这两个黑盒变成了“灰盒”。交互的概念表现在架构描述了它们之间的关
系，例如数据如何读取、功能如何调用等。
决策：架构决策不但表现了系统组织、元素、子系统的组织风格决策，还包括了非
功能性需求的决策，例如对于可扩展性的决策，对于表示逻辑与业务逻辑变化的隔
离，第三方工具包变化的隔离等，这就使架构有了弹性。
架构的组成 与决策是架构设计的两个基本概念，这两个概念并不矛盾，在架构设计中，
往往是同时体现这两个概念，确保架构满足产品要求。由这两个概念出发，我们自然会提出：
软件架构的核心思维到底是什么呢？
首先，任何软件系统都是以满足需求作为目的，所以，好的架构设计必须以全面深入的
需求分析作为基础，根据需求来组织合理的产品架构。事实上架构设计是没有统一的模式的，
任何模式只有针对问题才有意义。作为架构设计来说，必须对需求分析有足够的理解，这样
才能有针对性地解决问题，才可能设计出真正优秀的产品来。
其次，一个软件系统的质量，很大程度上是由架构设计的质量决定的，所以架构师的眼
光一般都专注于质量属性上，应该根据产品质量属性的要求提出合理的架构决策。但是很长
时间以来，人们大都把目光关注在流程、方法、结构原理甚至编码的本身，而不太注意架构
设计最本质的东西，思考的深度也欠深入，结果，很多产品即使设计出来，后期运行中也是
问题百出，特别是发生变更的时候带来了很大的困难。这就给我们提出了一个问题，架构设
计的思维到底是什么？
另一方面，任何架构思想的实现，必须与具体的项目组织相匹配才能发挥作用。因此，
系统架构师应该仔细研究现代项目管理的思想和方法，吃透其中的精髓，根据自己的设计思
想，提出合适的软件工程策略。反之，一个软件工程策略，也不可避免的也会影响到架构设
计的特点。因此，软件架构设计是一个系统工程，它需要系统构架师有很宽的知识面，从需
求分析、架构设计到类设计甚至代码实现一直到项目管理都需要有透彻的理解，这之间的关
系是你中有我我中有你，是不可能截然分开的。必须说明，软件系统设计的方法不是一个僵
化的规则，关键是在实践中实事求是的摸索规律，从而找出符合实际达到要求的设计来。