软件的质量是设计出来的，这是公认的基本观点。 -- 邓成飞， 《软件工程管理》

很少有需求文档能够以一种可测试的细节捕获系统所有的质量需求，现实情况是设计师通常不得不填补空白并协调冲突。 -- Len Bass, 《软件架构实践（第2版）》

核心竞争力是什么？答案是：能力的稀缺性。

接下来介绍的目标-场景-决策表方法，可以帮助架构师快速建立非功能目标的设计思维，更理性的应对架构师普遍感到棘手的非功能支持问题，提升自己的核心竞争力。

为了提高综合客户满意度及不同质量属性的满意度，必须考虑计划和设计产品时的不同质量属性。 -- Stephen H.Kan，《软件质量工程》

质量属性很难定义，但它们经常可以区分产品是只完成了其应该完成的任务呢，还是使客户感到满意。 ......优秀的软件产品反映了这些竞争性质量属性的优化平衡。 -- Karl E.Wiegers, 《软件需求(第二版)》

作为决策者，架构师的工作影响着项目的成败，乃至公司的发展。我们须谨记：千万不要做“四拍”型的决策者。

决策时拍脑袋--就这么定了
指挥时拍胸脯--保证没问题
失误时拍大腿--我怎么没想到
追查时拍屁股--老子不干了
架构设计实践中，面对非功能需求目标时是最容易犯“拍脑袋”这个经典错误的。接下来介绍非功能目标的设计思维及其实践要领。

非功能需求的满足程度对软件项目的成功非常关键......非功能需求分为质量属性和约束两大类。质量属性是软件系统的整体质量品质--所谓整体品质，就是往往和大多数功能都有关，而不是仅仅表现在某个功能“内部”。志宇约束性需求，它们是架构设计中必须遵循的限制，并有可能“衍生”出质量属性需求和功能需求。 -- 温昱，《软件架构设计》

那么非功能需求方面常见的问题是什么呢？......很多《需求规格说明书》中，会通过一个名为“设计原则”的小节来说明非功能需求，列出诸如高可靠性、高可用性、高扩展性等要求。但是很多开发人员根本不去看它，因为这样的定性描述是没有判断标准的，因此这种信息传递是无效的。 -- 徐峰， 《软件需求最佳实践》

压力、没时间进行充分测试、含糊不清的规格说明......无论多努力工作，还是会有错误，不过，造成无法挽回失败的，是数据库设计错误还是架构选择错误。 -- Stéphane Faroult，《SQL语言艺术》

针对不同的领域，由于信息资源类型及其存在的状态不同，信息资源整合的需求存在较大差异。 -- 彭洁，《信息资源整合技术》

确定数据分布方案是数据架构设计的难点。越是大系统，数据分布越关键。因此，一线架构师迫切须要建立数据分布策略的大局观。

我们接下来结合案例，讲讲如何运行数据分布的6种具体策略。

我认识一些架构师，他们的生活都是失控的。因为架构天性范围宽广，涉及人、工作量都非常多。一些架构师把他们的时间整天整天的花在跟“项目干系人”开会上，然后夜以继日，再搭上周末去实际的架构工作。 -- Eric Brechner, 《代码之道》

多重软件架构视图之所以必不可少，是因为各类涉众（用户、客户、开发人员、测试人员、维护人员、内部操作人员、其他人员）需要从各自角度理解和使用架构。 -- Barry Boechm

架构要涵盖的内容和决策太多了，超过了人脑“一蹴而就”的能力范围，因此采用“分而治之”的办法从不同视角分别设计；同时，这样也为对软件架构的理解、交流和归档提供了方便。

接下来会介绍物理架构、运行架构、开发架构作为软件架构的不同视图，它们分别关注不同的方面、针对不同的目标和用途。

有没有一种方法在大产品和小团队之间的缺口上架起一座桥梁呢？答案是肯定的，有！那就是架构。架构最重要的一点，就是它能把难以处理的大问题分解成便于管理的小问题。 -- Eric Brechner，《代码之道》

一流是每个程序设计人员向往并为之奋斗却又无法具体说出的、难以达到的境界，一流的软件非常简明。它灵活而清晰，能通过创造性的机制解决复杂的问题，这些机制语义丰富，可应用于其他可能完全无关的问题，一流意味着寻求恰当的抽象，意味着通过新的途径合理利用有限的资源。 -- Grady Booch，《面向对象项目的解决方案》

划分子系统、定义接口......，这些典型工作都是属于逻辑架构设计的范畴。

接下来，我们主要说说5视图方法中逻辑架构视图的设计：

先从划分子系统的3种必用手段讲起
随后，纠正“我的接口我做主”这种错误认识，代之以“协作决定接口”的正确理解
而且，接下来将解析逻辑架构设计的整体思维套路，解决架构师郁闷已久的“多视图方法只讲做什么、不讲怎么做”的问题
最后，总结逻辑架构设计的10条经验要点。

假设有一座漂亮的大房子，一个人站在房子的前面，一个人站在房子的后面，另外两个人分别站在房子的左右两侧。四个人看房子都有不同的视角，四个人都在争论自己看到的那一面是正确的一面，如果运用水平思考，那么这四个人就会绕房子一圈，分别看到房子前后左右四个面。 -- 爱德华.德.博诺，《六顶思考帽》

总的来说，“架构”一词涵盖了软件架构的所有方面，这些方面紧紧的缠绕在一起，决定如何将之分割成部分和主题显得相当主观。既然如此，就必须引入“架构视点”作为讨论、归纳和理解大型系统架构的手段 -- Peter Herzum, 《Business Component Factory》

架构设计是一门解决复杂问题的实践艺术。于是，以分而治之为思想核心的多视图方法必不可少。

接下来主要介绍支持细化架构设计的整体思路--多视图方法。

如果一个项目的系统架构（包括理论基础）尚未定义，就不应该进行此系统的全面开发。 -- Barry Boehm, 《Software Engineering》

如果选择视图的工作没做好，或者以牺牲气体视图为代价，只注重一个视图，就会掩盖问题以及延误解决问题。 -- Grady Booch, 《UML用户指南》

从概念架构到细化架构，先设计概念架构，构思关键问题的解决策略；再进行细化架构的设计，以保证为开发提供足够的指导和限制...这符合人类解决问题的规律，因此被广泛采用。

但在实际中，细化架构设计还存在很多差强人意之处，甚至经常被忽视。

架构不仅仅是系统功能需求的结果 -- Len Bass, 《软件架构实践(第二版)》

在我们当中，有不少人一厢情愿的认为：只要所开发出的系统完成了用户期待的功能，项目就算成功了，但这并不符合实际。 -- 温昱,《软件架构设计》

《软件架构设计》一书中指出，“其实任何作为复合整体的复杂事物都有可能有架构，比如一本书”。“非功能目标的考虑”在ADMEMS方法中不是一个阶段，而是一个贯穿环节。

我们接下来讨论的重点是贯穿案例 -- PASS系统概念架构设计的第3步，考虑非功能需求。

复杂性是层次化的。 -- Frederick.P.Brooks,《人月神话》

分析与综合是思维方向相反的过程。一部是先分析后综合，没有分析就不能综合；没有综合的分析，也只有片面的分析。 -- 肖纪美，《梳理人、事、物的纠纷：问题分析方法》

“架构 = 模块 + 接口”的做法，其不足可概括为两点。

第一，忽视了多视图。“模块 + 接口”仅是逻辑架构设计视图的核心内容，而软件系统的架构设计还可能涉及开发视图、运行视图、物理视图、数据视图等多方面的考虑。

第二，忽略了概念架构设计。对规模较大的系统而言，都必须先根据重大风险（包含功能方面、质量方面、约束方面），有针对性的制定包括“高层分割”在内的设计决策，然后才是“模块 + 接口”一级的设计。

那么，如何对软件系统进行“高层分割”呢？这属于Conceptual Architecture阶段第2步的工作。也真是这一章要说的主题。

好的开始是成功的一半。 -- 谚语

所谓鲁棒性分析时这样一种方法： 通过分析用例规约中的事件流，识别出实现用例规定的功能所需要的主要对象及其职责，形成以职责模型为主的初步设计 -- 温昱，《软件架构设计》

Conceptual Architecture阶段包含3个步骤：

第1步，初步设计。
第2步，高层分割。
第3步，考虑非功能需求。

”Use Case驱动“的观点既有积极意义，也有不利影响。从积极的方面看，Use Case这种需求描述方式确实有助于分析模型，设计模型，实现模型和测试模型的建立.....但是从另一方面看，OOSE对Use Case的依赖程度超出了它的实际能力。 -- 邵伟忠， 《面向对象的系统设计》

顶级设计者在设计中并不是按部就班地采用自顶向下（或自底向上）的方法，而是着眼于权重更大的目标。这些目标通常是难点问题，设计者不能轻易地看出这些问题的解决方案。为了得到整个的设计方案，设计者必须先致力于难点的设计并消除其中的疑惑。 -- Robert L. Glass, 《软件工程的事实与谬误》

概念架构是大型系统架构设计成败的关键。

胜兵先胜而后求战，败兵先站而后求胜。 -- 孙子，《孙子兵法 . 形篇》

人们常常使用战术，而忽略了战略。战略要求从大局上把握整个架构与设计......架构错误的代价非常高。 -- Stephane Faroult, 《SQL语言艺术》

架构新手和有经验的架构师的区别之一，在于是否懂得，并能有效的进行概念架构设计。作为架构新手，尤其害怕碰到自己没有做过的系统：系统较大时，一点祭出“架构 = 模块 + 接口”的发布却不太奏效，架构新手就往往乱了阵脚。想法，有经验的架构师不会一上来就关注与如何定义“接口”，他们在大型架构设计的早期比较注重识别重大需求、特色需求、高风险需求，据此来设计概念架构。

另外，概念架构设计还是投标及售后工作的有力武器。金牌售前和普通售前的一个重要区别是，能否清晰的讲解概念架构，并借此说明 “客户关系的价值如何实现、担心的问题如何解决”。

接下来，通过两个发生在身边的故事，来一窥上述不同工作（架构设计、投标、售前）背后的幕后英雄--概念架构。

“心念不同，判断力自然不同。” -- 严定道，《格局决定结局》

全面认识需求，是生成出高质量软件所必须的“第一项修炼” -- 温昱，《软件架构设计》
Pre-architecture 阶段包括4个步骤，咱们先讲讲前两步。

* 第1步，需求结构化
* 第2步，分析约束影响

架构设计对系统成败非常关键，那么，什么对架构设计的成败非常关键呢？

所谓的“开始就是结局”，要达到什么样的结局取决于什么样的开始，结局就是开始的地方。 -- T.S 艾略特，《四个四重奏》

需求验证的目标是尽可能的暴露问题，而不是证明无错。 -- 徐峰，《软件需求的最佳实践》

没有风险的软件早就被开发完了。

作为架构师，首先要面对的风险就是需求。既要关注功能需求，又要平衡互相矛盾的质量属性需求，还不能遗漏各方面的约束性需求...这，已经成为合格架构师必需的基本功。

接下来，3个真实故事都说明了这一点。

架构设计能力，因为掌握起来而显得珍贵。期望用这本手册来概括一线架构师经常面对的实践困惑，并给出ADMEMS方法的应对之策。