12月5日聊天备忘——关于构架的一些观点
　

---

(只是我和几位同事一起聊天时的记录整理，原文发布在www.marshine.com.粘贴后格式有些变化，如果需要查看格式更好的版本，请到www.marshine.com)
版本:1.0
修订:2002/12/10
作者:张玮
排版:marshine
参与者:张玮、魏猪头、marshine

======================================================================
12.5日晚，我和两位同事又来到KFC，来几杯可乐，找一个靠窗的位置，就开始天南海北的神吹。这是我们一些简单的乐趣，高升桥那家KFC是我们常去的地方。

在项目中，平常我们都会谈论关于构架的话题，然而“到底什么是构架？”，有人提出来。是啊，到底什么 是构架呢？有人说构架是项目的关键问题的决策，有人说构架软件逻辑结构的高级抽象；RUP中的构架是4+1视图，XP认为构架可以用隐喻(Metaphor)来表示，FDD看重领域模型在架构中的位置，也就是说，软件开发者时常挂在嘴边的“架构”(Architecture)并不容易找到一个标准的概念。

我个人比较同意“构架是项目的关键问题的决策”的观点，它应当有多个剖面(Profile)，也就存在不同的对于架构的描述，取决于关注者的重点。

我们开始在各个方面讨论关于构架的一些概念，以及对项目的影响。后来张玮把它整理出来，这便是这篇小文的由来。
======================================================================

从某种程度上说，系统本身就是架构，那为什么还需要提出架构这种概念甚至由某个或某几个专门的架构工程师或小组来负责主要制作并维护这些架构呢? 实际上，不论是否有架构工程师、专门的制作架构的活动或架构文档，任何一个系统都是有它的架构的。 就好象大多数文章，不管它是否有目录，是否有导读，它都是有自己的结构的。架构是系统的形或系统的神；同时架构（在大多数情况下）还可能影响项目组成员的组织；架构可以起到提纲契领的作用。

人们需要架构来:

了解系统--了解架构的目的就是(从某一个角度)了解系统，因此从这个角度上来说，架构就是为了交流(比如说某人对房子最关心的就是它的建筑面积)，既然是为了交流，当然需要一个顶层的描述，从而建立起对系统的总体映象。
做出并表达重大决策--描述架构是为了描述系统，但只有重大的决策才被列入架构。而这种决策是否重大，实际上从决定本身而言，项目中每个决定都是一样重要的，因此我们说某个决策是否重大，实际上是说这个决策对受众影响的重大程度及影响的范围是否更广，或者说要改变这种决策的难度的大小。
平衡协调--预先制作架构是因为架构影响的范围广，程度深。范围广就意味着需要多方协调，同时架构还意味着对多方进行权衡(平衡)，比如对多种需求多种技术进行权衡等。架构还可以用于多个小组之间的协调，它是多个小组之间的协议，同时它还包含多个小组共同的守则。
有专门架构小组或专门架构师是因为架构是对多方面需求多种涉众要求进行权衡并做出的重大决定，而这些因素互相约束，互相牵制并互相影响，因此需要有专门的人进行统一的协调(集中制)，当然也可能所有影响深远的决定由团队所有成员一起做出，统一进行协调(民主制)或有一种解决冲突并协调的机制(如隐喻，民主集中制等)。
屏蔽影响--架构稳定就意味着影响深远及需要多个地方都发生改变的变化不会频繁出现。
目录--就象一本书，需要一节前言来说明书的结构及表达的方式，如果你要想快速找到文章中关心的某一项内容，一般来说，你需要先查目录，架构也可以起到目录的作用。
认识到架构的这些特点，我们可以在应用中更好地使用架构：

架构就是系统，系统就是架构
既然描述架构就是描述系统(中的重要元素)，因此一切描述系统的手段都可用于描述及表达架构。
架构是重大决定，因为它影响深远
因此架构的确定方法与组织中确定大事的文化应相符，比如组织是一种民主制，则宜用民主制的架构方式，组织是集中制，则宜用集中制，如是民主集中制，则宜用民主集中制
架构元素应捡重要的元素说，所谓重要的元素，是指
共同的元素，
变化涉及多个部分的。
架构用于交流
因此描述架构的方法应用易于理解的方式来表达架构，比如简单，直接的方式，图画甚至动画等一切手段。
因此架构应该是面向不同受众的，比如用户和设计人员看待架构的角度就不会一样，他们的关注点也不会一样。比如一幢房子，用户可能比较关心地段、户型、面积等，而开发商可能更关心成本及收益等，而建筑商可能更关心其中的通用件是否多，是否容易施工。换句话说，如果给你十分钟对初次接触系统的人描述系统，对用户和对设计人员，编码人员，测试人员等你所讲的话肯定会不一样，但是它们又都是描述同一个东西的。
架构用于平衡协调
因此架构中应包含这两部分内容:划分的部分及各部分之间的接口，各部分之间共同的约定。

如果项目组本身成员之间的关系就比较和谐，协调比较方便，重大事项的决定可以集体决定，就可以没有专门的人负责维护架构(但并不是没有人维护架构，没有人维护和所有人维护是完全不同的）。

架构工程师需要有(技术上及人员组织协调的)经验。
各种技术的平衡及协调也是架构工程师所需要做的一件重要的事情。
屏蔽影响
一个好的架构应使系统趋于收敛，意即架构使系统变化引起的改变及影响越来越小。

其实，软件构架的概念是可以很通俗地来理解的，不需要太多的术语来解释，也不需要搬出各种软件构架的表现形式和实现方法来代替。
如果你知道建房子有结构设计，建桥梁有结构设计，碳原子按不同的结构组织就会表现出不同的性能，你就会知道：“结构”是任何事物内在的一种决定性属性。软件，作为一个一般意义上的系统，也有其结构。这就是软件的构架。
结构就是系统各元素之间相互依存，相互作用，项目制约的一种状态，甚至还包含这种状态演化的规律和机理。
要成为构架设计师，光懂得软件是远远不够的。
学一点系统科学，会加快成为优秀的构架设计师的进程。

 至少目前来看不能简单的说architechture和structure就是同一回事。
　

---

这里面的很多提法实际上是很多大师的提法。不要一来就是一股说教的口气，你明白什么告诉大家就行了。

 回复: 12月5日聊天备忘——关于构架的一些观点
　

---

该文关于架构的观点有点偏了，此处的架构到底是开发团队的组织架构，
还是开发过程中的应用架构，系统架构，不能混为一团！
此处将RUP的开发过程的组织架构同开发的产物中的应用架构，系统架构混淆了！

 嘿嘿，只希望这些观点拓宽一下理解的范围，每人有自己的理解。
　

---

谁又敢说软件开发没从建筑中获取灵感，像设计模式的GOF发现《建筑的永恒之道》带来的灵感，而《建筑的永恒之道》似乎又闪耀着中国道家的思想。
我的一个同事谈开发的节奏之美想起了交响乐。

软件结构不一定就是类图或模块图。
想到节奏不仅仅是迭代周期。
模式并不仅存在于建筑、软件设计
构架也不仅仅是逻辑结构。

但我承认，如果大家的架构就是逻辑设计结构（像顶层包、类图，多层分布式这些概念），那就是它了。

至少避免了一开始就陷入一大堆大师们的高深和精辟的论述中,不知所在.
你公布的观点很好,很有水平,我只是对入门者一个补充.
谢谢你的忠告.