架构设计–仅是软件开发之第二大影响力？！

SDWest2006（译注1）对我来说是个有趣的大会。我除了星期三之外（当时我正飞往费城参加一个客户会议 == 因此错过了Jolt颁奖部分）每天都在演讲。我也参加了一些谈话和会议；其中最引人关注的是Mike Cohn的计划与估算的谈话。我的两个谈话都是半天的关于Ood原则类设计之高级原则    在OO设计中，掌控类间组合或是关联关系的原则到底是什么/span>

在星期二我主导了一个关于“敏捷与架构设计”的圆桌会议。很多人是挤着进入会议现场的，而且一直参与到会议结束。配合着讨论要点的导航图，我们将这些要点一一讨论过。我的好朋友John Kern也在那儿，还帮助解答了很多提问。你可以从这里了解更多有关这个会议的。

会议的一些关键要点如下：

1. 架构设计的主要目标是灵活性，可维护性和可扩展性。
2. 但我们认识到，由测试驱动开发原则指导产生的单元测试和验收测试（译注2）要比灵活性，可维护性和可扩展性来得更重要。
3. 因而测试才是首要的影响力，而架构设计只是第二位的。

在此次会议前，我从未想到过这点。这里就有一群架构师和设计师，他们激烈的争辩着架构设计的角色和位置，可是我们辛苦争论出的一致结论是灵活性，可维护性和可扩展性是处于次要的影响作用的，是编写测试（测试优先于产品代码）起着最主要的效用。

这好像是吞下了苦黄莲，而且很多架构设计师们搞不好立即就会拒绝。然而，没人认为架构师不重要，或者认为应该丢掉它转而去青睐测试。正相反，是测试让我们无所顾虑的改进系统的设计。不是测试胜于架构设计；而应该说是测试成全了它！

自动化测试给了我们一个可靠的方式去了解系统是否运行良好。因此我们不必再惧怕一个设计的改变会破坏它。这让实施那些能够改进系统的设计变得更容易。因此测试的粉末登台意味着在持续改进系统的结构、设计和架构时遇到的阻碍会来得更少。

失去测试，架构设计就是天方夜谭，因为一但重大的开发启动后设计将很难改变。而自动化测试给设计留下了空间。设计改变所带来的风险如此之大的被削减，以至于我们可以在肆无忌惮中就让系统进化。

（原文链接网址：http://www.butunclebob.com/ArticleS.UncleBob.ArchitectureIsaSecondaryEffect; Robert C. Martin的英文blog网址： http://www.butunclebob.com/ArticleS.UncleBob） 

架构设计的三个维度

架构设计是一个非常大的话题，不管写几篇文章，接触到的始终只是冰山一角，更多的是实践中去体会。

这篇文章主要介绍的是面向对象OO，面向方面AOP，面向服务SOA这三个要素在架构设计中的位置与作用。

一、架构设计三个维度

架构设计有三个维度，或者说是我们在考虑架构时需要思考的三个方向。分别为：面向对象、面向方面、面向服务。这三个维度可以看作是正交的，但不同维度会互相印证，互相支撑。

整个架构的示意图如下所示：

二、面向对象

面向对象技术最初是从面向对象的程序设计开始的，它的出现以60年代simula语言为标志，……如此看来，架构师应当为项目相关的不同角色而设计（如图架构师要为客户负责，满足他们的业务目标和约束条件；

l        架构师要为用户负责，使他们关心的功能需求和运行期质量属性得以满足；

l        架构师必须顾及处于协作分工“下游”的开发人员，

l        架构师还必须考虑“周边”的管理人员，为他们进行分工管理、协调控制、评估监控等工作提供清晰的基础。

图一言以蔽之，软件架构师必须做到内外兼顾、各层并重（如图 

补充三点：

●这个话题我在2006IBM开发者大会的预热课堂上有过演讲，说明了如何运用基于多视图的架构设计方法应对上述问题。

●另外可参考我在IBM DW上发的文章：运用RUP 4+1视图方法进行软件架构设计

●其实，《软件架构设计》一书讲述的具体方法和4+1方法有所不同……例如，明确引入“质量属性分析”活动来为性能、可伸缩性、可重用性、可扩展性等非功能需求制定相应的架构决策。书的第15章专门介绍质量属性分析（例如如何运用“质量-场景-决策”表这种思维工具落实需求、制定设计决策等）。

文章知识点与官方知识档案匹配，可进一步学习相关知识MySQL入门技能树首页概览31345 人正在系统学习中

来源：叶广明_微信ye_guangming