hnxxcxg架构的一些关点.txt

f your application uses MFC in a shared DLL, and your application is in a language other than the

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

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

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

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

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

人们需要架构来: 

　　了解系统--了解架构的目的就是(从某一个角度)了解系统，因此从这个角度上来说，架构就是为了交流(比如说某人对房子最关心的就是它的建筑面积)，既然是为了交流，当然需要一个顶层的描述，从而建立起对系统的总体映象。 

　　做出并表达重大决策--描述架构是为了描述系统，但只有重大的决策才被列入架构。而这种决策是否重大，实际上从决定本身而言，项目中每个决定都是一样重要的，因此我们说某个决策是否重大，实际上是说这个决策对受众影响的重大程度及影响的范围是否更广，或者说要改变这种决策的难度的大小。 
平衡协调--预先制作架构是因为架构影响的范围广，程度深。范围广就意味着需要多方协调，同时架构还意味着对多方进行权衡(平衡)，比如对多种需求多种技术进行权衡等。架构还可以用于多个小组之间的协调，它是多个小组之间的协议，同时它还包含多个小组共同的守则。 

　　有专门架构小组或专门架构师是因为架构是对多方面需求多种涉众要求进行权衡并做出的重大决定，而这些因素互相约束，互相牵制并互相影响，因此需要有专门的人进行统一的协调(集中制)，当然也可能所有影响深远的决定由团队所有成员一起做出，统一进行协调(民主制)或有一种解决冲突并协调的机制(如隐喻，民主集中制等)。 

　　屏蔽影响--架构稳定就意味着影响深远及需要多个地方都发生改变的变化不会频繁出现。 
目录--就象一本书，需要一节前言来说明书的结构及表达的方式，如果你要想快速找到文章中关心的某一项内容，一般来说，你需要先查目录，架构也可以起到目录的作用。 
认识到架构的这些特点，我们可以在应用中更好地使用架构： 

架构就是系统，系统就是架构 
　　既然描述架构就是描述系统(中的重要元素)，因此一切描述系统的手段都可用于描述及表达架构。 
　　架构是重大决定，因为它影响深远 
　　因此架构的确定方法与组织中确定大事的文化应相符，比如组织是一种民主制，则宜用民主制的架构方式，组织是集中制，则宜用集中制，如是民主集中制，则宜用民主集中制 
　　架构元素应捡重要的元素说，所谓重要的元素，是指 
共同的元素， 
　　变化涉及多个部分的。 

架构用于交流 
　　因此描述架构的方法应用易于理解的方式来表达架构，比如简单，直接的方式，图画甚至动画等一切手段。 
　　因此架构应该是面向不同受众的，比如用户和设计人员看待架构的角度就不会一样，他们的关注点也不会一样。比如一幢房子，用户可能比较关心地段、户型、面积等，而开发商可能更关心成本及收益等，而建筑商可能更关心其中的通用件是否多，是否容易施工。换句话说，如果给你十分钟对初次接触系统的人描述系统，对用户和对设计人员，编码人员，测试人员等你所讲的话肯定会不一样，但是它们又都是描述同一个东西的。 

架构用于平衡协调 
　　因此架构中应包含这两部分内容:划分的部分及各部分之间的接口，各部分之间共同的约定。 

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

架构工程师需要有(技术上及人员组织协调的)经验。 
　　各种技术的平衡及协调也是架构工程师所需要做的一件重要的事情。 

屏蔽影响 
　　一个好的架构应使系统趋于收敛，意即架构使系统变化引起的改变及影响越来越小