《软件架构设计》学习笔记（转）

架构的概念

在软件行业，架构的概念一直没有一个完整、统一的定义，软件架构的概念分为主要量大派别：组成派和决策派。组成派认为软件架构是：软件系统的架构将系统描述为计算组件及组件之间的交互，“组件”是普遍意义上的元素，并非指具体的技术组件。组成派的定义关注架构实践中的客体——软件，以及软件自己为描述对象；另外分析了软件的组成，即软件由承担不一样计算任务的组成组件，这些组件经过相互交互完成更高层次的计算。而决策派认为，软件架构保护了软件设计过程当中一些列问题的重要决策，软件架构并不只仅关注软件自己的结构和行为，还注重其余特性：使用、功能、性能、弹性、重用、可理解性、经济、和计算限制、权衡、以及美学等。决策派的定义更关注架构实践中的主体——人，以人的决策为描述对象，而且概括了架构决策的类型，指出架构决策不只包括关于软件系统的组织、元素、子系统和架构风格等几类决策，还包括关于众多非功能需求的决策。

说的更通俗一点，组成派关注架构的结果，而决策派关注架构的过程。而笔者认为，架构的是一个演进的过程，没有一成不变的架构，也没有一蹴而就的架构，架构须要根据业务的发展而进行相应的调整，因此咱们应该更加关注架构演进的过程和缘由，以及在当时背景下的作出的权衡和妥协。没有完美的架构，架构也没有一个标准的解决方案，由于面对不一样的业务需求，面对不一样的客观因素，有不一样的架构设计方案，也就是有不一样的设计决策。组成派和决策派的架构概念并不矛盾，它们只不过是所站的角度不一样罢了：在具体的软件架构实际中，老是同时体现这两“派”的架构概念。 架构决策是分层次依次展开的，决策制定的顺序每每是先制定技术无关的决策，后制定技术相关的决策，后者在前者的指导下进行。架构师必定要考虑更多的实际开发中要涉及到的技术问题，从而不断细化架构方案，这样才能为开发人员提供更多的指导和限制，也才能真正下降后续开发中的重大技术风险。因此，架构师的架构方案不是高来高去的，而是须要可以落地的，而且在落地的过程当中遇到的技术细节问题，架构师是须要参与解决的。这样架构师才能与开发人员无缝对接，架构方案才能指导开发人员进行开发。

子系统、框架和架构

好的架构必须使每一个关注点相互分离。把变化点错落有致地封装到软件系统的不一样部分（笔者感悟：封装的思想在软件工程中，无处不在啊！），为此，必须进行关注点分离。经过关注点的分离来达到“系统中的一部分发生了变化，不会影响其余部分”的目标。能够经过以下的一下手段：

一、 经过职责划分来分离关注点。面向对象设计的关键所在，就是职责的识别和分配。不管是对象、模块，仍是子系统，它们所承担的职责都应该具备高内聚性，不然对象之间的松耦合性就失去了基础，成为空谈。因此咱们一直在提“高内聚、低耦合”，高内聚才是低耦合的基础。而咱们常用的设计模式和架构模式为特定上下文中重复出现的问题提供了通用的职责划分方案，也是问题解决方案。

二、 利用软件系统各部分的通用性的不一样进行关注点分离。不一样的通用程度意味着变化的可能性不一样。这一点与面向对象设计里面的重用发布等价原则殊途同归。

三、 先考虑大粒度的子系统，而暂时忽略子系统是如何经过更小粒度的模块和类组成的。避免陷入过多的细节当中，所谓“忘倒是一种能力”，就是指架构师必须有在更高层面思考的能力。 根据职责分离关注点、根据通用性分离关注点、根据不一样粒度级别分离关注点是3种位于不一样“维度”的思惟方式，咱们能够综合运用这些手段。

不管是架构模式仍是设计模式，重点关注的都是如何提供一个“协做模型”，这个协做模型经过明确协做中不一样的角色锁担任的职责，达到“为特定上下文的问题提供解决方案”的目的。

框架技术有助于把通用关注点和专用关注点分离开来，结果是带来了更好的易修改性和可重用性。

做为架构师，必须思考“软件单元是如何组成粒度更大的总体的”这一问题。类、模块、子系统、系统、集成系统，都是软件单元的具体形态，只不过粒度不一样罢了。软件系统越复杂，不一样粒度的分解层次就越多。这里所谓的系统，是指由多个元素组成的逻辑实体，它完成一组特定的目标或负担必定的职责。系统能够仅包含软件，也能够仅包含硬件，或者二者都包含。子系统是特殊的系统，只不过在特定的上下文中，这个系统做为更大系统的一部分出现。系统须要架构设计，而子系统若是足够复杂，则也须要架构设计。而不一样类型的软件系统须要不一样的软件架构设计，一个系统的不一样子系统也应当有不一样的软件架构。

固然，一个系统的粒度是具备相对性的，同一个软件单元，在不一样场景下，咱们会以不一样的粒度看待它。全部的系统都有子系统，而全部系统都是更大系统的子系统。实践不一样场景使得软件组成单元具备递归性。懂得了细节是相对而言的这一点，软件架构师才可以游刃有余地根据状况忽略应该被忽略的细节，抓住设计大局。

框架的概念，框架是一种半成品。是能够经过某种回调机制进行扩展的软件系统或子系统的半成品。框架从某种程度上来讲，是为了软件重用。而软件重用自己又有一对内在的矛盾，即重用概率和重用价值，重用概率大小和重用带来的价值大小之间的矛盾。软件单元的粒度越大，可重用的概率就越小，但其重用所带来的价值就越大，相反，软件单元的粒度越小，可重用概率就越大，但其重用所带来的价值就越小。框架的智慧就在于此：为了追求重用所带来的价值最大化，将容易变化的的部分封装成扩展点，并辅以回调机制将它们归入框架的控制范围以内。 对软件架构的误解，其中一个最为广泛的就是，将架构（Acrchitecture）和框架（Framework）混为一谈。框架是软件，而架构不是软件。框架是一种特殊的软件，它并不能提供完整的解决方案（准确说，是不提供业务应用的完整解决方案，而框架自己也是为解决某一类问题而出现的），而是为构建解决方案（这里的解决方案便是业务应用的解决方案）提供良好的基础，因此说，框架是半成品。框架中的服务能够被最终应用直接调用，而框架中的扩展点是供应用开发人员定制的“可变化点”。而软件架构不是软件，而是关于软件如何设计的重要决策。软件架构决策涉及到如何将软件系统分解成不一样的部分、各部分之间的静态结构关系和动态交互关系等。这些架构决策将体如今最终开发出的软件系统中。引入软件框架以后，整个开发过程变成了分两步走，而架构决策每每会体如今框架之中。软件架构是比具体代码高一个抽象层次的概念。架构势必被代码所体现和遵循，但任何一段具体的代码都表明不了架构（这里说的有点绝对，某一段具体的代码，表明不了整个架构，有时却能够表明某一个架构决策）。框架技术和架构技术的出现，都是为了解决软件系统日益复杂所带来的困难而采起“分而治之”的思想。先大局后局部，就出现了架构；先通用后专用，就出现了框架。架构是问题的抽象解决方案，它关注大局而忽略细节；框架是通用半成品，还必须根据具体需求进一步定制开发才能变成应用系统。固然，框架也有架构，并且很重要。框架和架构既有区别又有联系，前者是复合组件特例，后者是复合组件的大局设计。软件架构须要落地，须要了解细节，但也没有必要将全部设计决策事无巨细地落实，而是重点关注“重要决策”。软件架构设计的决策范围，应该着重放在“影响全局”的设计上，而不是所关注全部设计细节。

对面向对象开发而言，类库和框架有不少共同之处，但它们确确实实又是不一样的。类库是类的集合，这些类之间多是相互独立的。与类库相比，框架和类库有着类似的形式，即框架也每每是类的集合，但不一样之处在于，框架中的各个类不是孤立的，而框架中的业务逻辑代码是将不一样的类“连”在一块儿，在它们之间创建协做关系。框架经过封装处理流程的控制逻辑，使它对开发者透明，来简化开发工做。这种封装也是框架和类库的区别之一。

框架能够分为应用框架、中间件框架和基础设施框架三大类，造成了“应用软件——中间件——基础设施”的宏观格局。框架也能够分为技术框架和业务框架。技术框架又称为水平框架，业务框架有称为垂直框架。框架的整个开发过程，包括四个主要阶段，即分析、设计、实现和稳定阶段。和应用开发同样，框架开发首先要肯定框架的范围和目标。对特定领域框架层和跨领域框架层都要识别出通用点和扩展点，其次，为框架设计架构，将它用做实现阶段的蓝图。在设计阶段，也能够建立应用程序框架原型，而后在其上构建一个样本应用，并洞察框架设计中潜在的可改进之处。框架开发的稳定阶段还应提供相应的框架文档。面向对象技术的发展极大提够了框架的能力，并推进了框架技术被广泛接受。面向对象框架的组成部分包括具体类、抽象类和接口。抽象方法是面向对象支持“多态”的关键，面向对象框架借助抽象方法实现逆向控制。许多面向对象框架在利用抽象方法支持扩展的同时，还会借助“配置驱动”来下降使用框架的难度。框架也须要架构设计，但反过来，能够经过架构框架化，达到“架构重用”的目的。

软件架构的做用

软件架构对后期的软件维护，乃至改动力度比较大的软件升级都起着重要做用。由于软件架构给出了软件系统的一个全局的视角。对软件系统不断的修改会使系统架构慢慢变得混乱，由于业务的发展，是会慢慢腐蚀现有的系统架构的，因此架构须要根据业务的发展进行演进。 软件架构设计为何这么难？由于它是跨越现实世界与计算机世界之间鸿沟的一座桥。从面向业务的需求，到最终的面向技术的软件系统，要跨越很大的鸿沟。软件架构设计就是要完成从面向业务到面向技术的转换，在鸿沟上驾起一座桥梁。软件架构包含告终构、协做和技术等方面的重要决策，为系统化的开发活动创建了基础。

架构的做用包括以下几个方面：

一、 上承业务目标：担负着完成业务目标而进行大局规划的职责。

二、 下接技术决策：软件架构师将面向业务的需求转化为面向技术的软件架构设计方案，为后面的技术开发工做提供了切实的指导和限制。

三、 控制复杂性：先进行架构设计，后进行详细设计和编码实现，运用了“基于问题深度分而治之”的理念，利用控制复杂性。

四、 组织开发：软件架构为开展系统化的团队开发奠基了基础，它规定了软件系统的各元素如何彼此相关的设计决策，从而能够把不一样模块分配给不一样小组分头并发进行，而软件架构设计方案在这些小组中间扮演了“桥梁”和“合做契约”的做用。

五、 利用迭代开发和增量交互

六、 提升质量：清晰的软件架构将各个模块的职责划分得有条不絮，每一个模块都有清晰的接口，这至关于间接下降了开发难度。

软件架构会“磨损”——随着对软件系统不断地修改，软件架构将变得混乱。

所谓软件架构重构，是指对软件架构进行比较大的修改和调整，使它适应新需求及开发和维护的须要。软件架构重构属于“再工程”的一种状况，通常会经历逆向工程、从新规划、正向工程三个步骤。只有充分理解原有架构的设计思路，才能评估它在如今需求状况的“利”和“弊”，把合理的设计保留下来，把不妥的设计修改掉。

软件架构视图

方法指导过程，过程包含步骤。

所谓软件架构就是关于如何构建软件的一些最重要的设计的决策，这些决策每每是围绕将系统分为哪些部分、各部分之间如何交互展开的。不一样的涉众看待软件架构的视角是不一样的。软件架构是抽象的概念，因此在软件架构概念与实践之间，彷佛存在某种“鸿沟”——即缺失某种概念，而这种概念能够“连接”软件架构的概念和实际的开发实际的须要，为不一样涉众理解和交流架构提供更专注的视角。为了在软件架构纯概念和实践之间搭起一座桥梁，能够引入软件架构视图的概念。软件架构师应当时时牢记：为用户而设计，不只知足用户要求的功能，也要达到用户指望的质量。架构师也必须为客户而设计，适合的才是最好的。架构师还应该为开发人员而设计，关注软件的“开发期质量属性”（可扩展性、可移植性、易理解性和易测试性等非功能需求，都是属于软件开发期质量属性），为开发人员而设计。软件愈来愈复杂，单兵做战已经再也不是广泛的软件开发方式，取而代之的是团队开发，而团队开发又反过来使软件开发更加复杂，由于如今不只仅要面临技术复杂性的问题了，还有管理复杂性的问题。软件架构从大局着手，就技术方面的重大问题作出决策，构造一个由粗粒度模块组成的解决方案，从而能够把不一样模块分配给不一样小组分头开发。另外一方面，软件架构设计方案规定了各模块之间如何交互的机制和接口，在开发小组之间起到“沟通桥梁”和“合做契约”的做用。配置管理员应该可以从软件架构方案中了解到开发出来的软件以什么样的目录结构存在，以及编译事后的软件目标模块放到哪一个目录等决定，并以此做为制定配置管理基本方案的基础。因此，架构师应该为项目相关不一样的角色而设计。软件架构师必须作到内外兼修、各层并重。只有这样，软件架构才能和它“包含了关于如何构建软件的一些最重要的设计决策”的“地位”相符。

一个软件架构视图是对与从某一视角或某一点上看到的系统所做出的简化描述，描述中涵盖了系统的某一特定方面，而省略了与此方面无关的实体。软件架构的每一个视图分别关注不一样的方面，针对不一样的目标和用户。软件架构师应当提供不一样的软件架构视图，以便交流和传递设计思想。每一个软件架构视图关注软件架构不一样的方面，使问题得以清晰和简化，利于软件架构师完成架构设计的工做。项目不一样角色观察软件架构的视角各不相同，每一个视角涉及的需求和技术也不尽相同，因此将软件架构视图用做软件归档的手段是顺利成章的：但更为重要的是，软件架构视图能够被相对独立地分析和设计，这就使得软件架构师能够暂时撇开其余问题、专一于特定问题进行深刻的分析和设计。

最经常使用的两种架构视图：逻辑架构视图和物理架构视图。当观察和描述事物大局的时候，逻辑架构和物理架构是最经常使用的角度。软件逻辑架构设计的三大核心任务：识别功能块；规划功能块的接口；明确功能块之间的使用关系和使用机制。软件的逻辑架构是架构设计思惟的重要方法。用例技术已经成为捕获功能需求的事实标准，因此逻辑架构的设计每每是从用例分析开始的。基于用例的分析方法使逻辑架构的设计变得比较有序——经过对每一个关键用例的分析，从逻辑上将用例实现为一组功能块的特定组合，最后综合这些用例分析成果，获得整个软件系统的逻辑架构。物理架构能够反映出软件系统运行时的组织状况。“物理元素”就进程、线程以及做为类的运行时实例的对象等，而进程调度、线程同步、进程或线程通讯等则进一步反映物理架构的动态行为。物理层和分别有关，经过将一个总体的软件系统划分为不一样的物理层次，能够把它部署到分别在不一样位置的多台计算机上，从而为远程访问和负载均衡等问题提供了手段。物理层是大粒度的物理单元，它最终是由粒度更小的组件、模块和进程等单元组成。逻辑架构和物理架构是软件架构设计的重要方面。逻辑架构致力于将软件系统分解成不一样的逻辑单元，并规定这些逻辑单元之间的交互接口和交互机制。物理架构则更重视软件系统运行时的动态结构，以及组成软件系统的目标程序如何部署到硬件上。逻辑架构中关于职责划分的决策，体现为层、子系统和模块等的划分决定，从静态视角为详细设计和编程实现提供切实的指导；有了分解就必然产生协做，逻辑架构还规定了不一样逻辑单元之间的交互接口和交互机制，而编程工做必须实现这些接口和机制。所谓交互机制，就是指不一样软件单元之间的交互手段。交互机制能够是本地方法调用、基于RMI的远程方法调用、异步消息等。至于物理架构，它关注的是软件系统在计算机中运行期间的状况。软件的物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等需求。物理层做为组成软件系统的物理单元，最终又要映射到具体的硬件，这也是物理架构设计要考虑的，对于分布式软件系统的设计而言尤为不可或缺。

不一样的视图支持不一样的目标和用途。

软件架构师有许多工做要作：

一、要知足性能、持续可用性等方面的需求，架构师必须深刻研究软件系统运行期间的状况、制定相应的设计决策，这些需求被称为软件的“运行期质量属性”；

二、而要知足可扩展性、可重用性等方面的需求，则要求架构师深刻研究软件系统开发期间的状况，制定相应的设计决策，这些需求被称为软件“开发期质量属性”；

三、约束是一类特殊的需求，带有必定强制性，架构师制定的架构决策必须知足这些限制；

四、为了知足功能需求，架构师必须规划组成软件系统的全部模块，为他们分配不一样职责，使这些模块能够经过协做完成功能需求。

架构师必须明确区分功能需求、约束、运行期质量属性和开发期质量属性等不一样种类的需求。

架构设计的5视图方法包括：逻辑架构、开发架构、运行架构、物理架构、数据架构。逻辑架构关注功能，它们多是逻辑层、功能模块和类等。开发架构关注程序包，不只包括要编写的源程序，还包括能够直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。运行架构关注进程、线程、对象等运行时概念，以及相关的并发、同步、通讯等问题。物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装和部署到物理机器上，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。数据架构关注持久化数据的存储方案，不只包括实体及实体关系的数据存储格式，还可能包括数据传递、数据复制和数据同步等策略。

逻辑架构的设计着重考虑功能需求，系统应当向用户提供什么样的服务。逻辑架构的关注点主要是行为或职责的划分。逻辑架构的静态方面关注抽象职责的划分，其动态方面关注承担不一样职责的逻辑单元之间的交互。开发机构的设计着重考虑开发周期质量属性，例如可用性、可扩展性、易理解性和易测试性等。开发架构的关注点是在软件开发环境中软件模块的实际组织方式。运行架构的设计着重考虑运行期质量属性，例如性能、可伸缩性、持续可用性和安全性等。运行架构的关注点是系统的并发与同步等问题，这势必涉及到进程和线程等技术。运行架构的静态方面关注软件的运行时单元结构，其动态方面则关注运行时单元之间的交互机制。物理架构的设计着重考虑“安装和部署需求”，另外物理架构还应关注相关的可靠性、可伸缩性、持续可用性、性能和安全性等方面。数据架构的设计着重考虑“数据需求”。数据架构的关注点是持久化数据的组织、数据传输、数据复制和数据同步等策略。

五种架构视图，反映的是同一个软件系统的不一样设计方面，它们最终合在一块儿才是完整的架构设计方案，因此不一样的架构视图之间势必有相互支撑的关系。所谓保持架构视图之间的同步，就是保证不一样视图之间是相互解释而不是相互矛盾的。若是须要，能够引入新的架构视图，从而更加突出和明确地制定和表达特定方面的架构决策。另外，约束是必须遵照和考虑到的，每一个架构设计视图都应该注意这一点。五种不一样的元素撑起了不一样的思惟空间，从而使每一个架构视图重点覆盖不一样种类的需求。

概念架构和实际架构

实际的软件架构设计过程是，通常应先进行概念性架构的设计，把最关键的设计要素和交互机制肯定下来，而后再考虑具体技术的运用，设计出实际架构。概念性架构是对系统设计的最初构想。概念性架构没有严格的定义，并且也不该该过于严格的定义。概念性架构包括一些高层次的设计选择，对将来软件系统的质量和功能都起着关键影响。复杂系统的设计每每不能一蹴而就，而概念性架构就是最初的架构设计成果。

经典的分层架构的层指逻辑层（Layer），而如今的分布式应用的分层架构是指物理层（Tier）。逻辑层是一种功能和职责的组织单元，而物理层要求功能和责任的高聚合性，只不过每每是经过多个逻辑层映射到一个物理层这种方式实现的。

虽然概念性架构都跳不出“架构=组件+交互”的基本定义，但它们描述架构的具体方式仍是差别很大的：有的重视逻辑层，有的重视物理层，有的经过隐喻代表机制，有的看上去彷佛就是一些设计元素的组合。不一样的概念性架构图中，“链接”所表明的含义千差万别：有的是依赖方向，有的是控制方向，有的是数据流向。因为概念架构的高度抽象性，使得同属一类的许多软件产品的概念性架构是趋同的。概念性架构很是类似，实际架构却可能有很大的差别。概念性架构每每和具体技术的运用、具体平台的选择无关，而实际架构很是关心这些问题。实际的架构设计方案应该兼顾不一样的架构设计视图。概念性架构所包含的高层设计决策终究不会跳出以下多种架构视图的范围——逻辑架构、物理架构、开发架构、数据架构和运行架构。而实际架构必须设计到能够指导开发的程度。但务实地来说，概念性架构常常从逻辑架构和物理架构的角度制定高层设计决策。

概念性架构是不可直接实现的。概念性架构和实际架构的一些区别，主要涉及到开发人员最关心的点：

一、接口如何定义；

二、子系统如何划分；

三、各子系统或模块之间的如何进行交互；

共同点：概念性架构和实际架构都知足软件架构的概念——不管是“架构=组件+交互”，仍是“架构=重要的决策集”。

分层架构每每是咱们架构思惟的开始，在“分层”的基础上如何深刻，细化设计，如何调整每每是架构设计的关键。

概念性架构每每和具体技术的运用和具体平台的选择无关，而实际架构则很是关系这些问题，概念性架构并不规定要采用OO技术，但设计实际架构时每每要考虑如何充分利用OO技术来实现概念性架构。从概念性架构到实际架构，先设计概念性架构，构思关键问题的解决策略；再进行实际架构设计，以保证为开发提供足够的指导和限制。

成功的架构设计

好的架构应当具备以下品质：

一、良好的模块化。每一个模块职责明晰，模块之间松耦合，模块内部高聚合并合理地实现了信息隐藏。

二、适应功能需求的变化，适应技术的变化。应该保持应用相关模块和领域通用模块的分离，技术平台相关模块和独立于具体技术的模块相分离，从而达到“隔离变化”的效果。

三、对系统的动态运行有良好的规划。

四、对数据的良好规划。

五、明确、灵活的部署规则。

软件架构师的工做成功要为整个软件开发团队的工做提供足够的指导和限制，使他们可以沿着正确的方向进行下去。软件架构师开展架构设计工做，都是以《软件需求规格说明书》为最主要的设计依据的，都是先勾画出概念性架构，再结合具体技术平台制定实际架构。

非功能需求来自何处？一部分非功能需求来自用户。用户要功能，用户也要质量。为用户而设计，不只要知足用户要求的功能，也要达到用户指望的质量。一部分非功能需求来自开发者和升级维护人员。软件的可扩展性、可重用性、可移植性、易理解性和易测试性等非功能需求，都属于“软件开发期质量属性”之列。还有一部分非功能需求来自客户组织。非功能需求对架构设计很是重要。非功能需求是最重要的“架构决策因素”之一。非功能需求大体分为质量属性和约束两大类。约束性需求，它们要么是架构设计中必须遵循的限制，要么转化为质量属性需求或者功能需求。架构设计过程当中必须重视非功能需求。功能很重要，当架构师不能仅盯着功能需求，若忽视了非功能需求，则可能致使架构设计的失败。

架构师必须具有“忘却”的能力，避免涉及太多的具体的技术细节。软件架构必须为开发人员提供足够的指导和限制。软件架构师须要掌握趋于系统化的方法。对待复杂性的办法就是分而治之，和分而治之相伴相生的“综合考虑”也是不可或缺的。

软件架构设计强调的是总体，而总体性的设计决策必须基于对需求的全面认识。全面认识需求，是生产出高质量软件所必须的“第一项修炼”。要全面认识需求，咱们必须从不一样级别来考察需求：组织级、用户级、开发级，还要对每一个级别考虑不一样类型的需求：功能需求、质量属性、约束。全面认识需求还有一层含义，那就是应当在深思熟虑以后做出适合的需求权衡和取舍。一方面，众多质量属性需求之间每每会有冲突，咱们必须权衡。另外一方面，若是经过复杂设计所支持的变化根本不会发生，那么这种过分设计就形成了资源的浪费并增长了开发的难度。 让关键需求决定架构。功能需求数量众多，应该控制架构设计时须要详细分析的用例个数；另外一方面，不一样质量属性之间每每具备相互制约性，因而咱们天然应该权衡哪一部分质量属性是架构设计的重大目标。需求来自与实践须要，而实践是发展的，因此“肯定的需求”只是相对的。咱们通常在项目的业务目标以核心需求达成共识以后就开始架构设计，关键需求决定架构的策略很是适合。

应对软件架构设计方案进行验证，而不只仅是评审。应真正地经过编码将架构实现；应实际对架构原型进行测试，测试的重点是运行时质量属性；要认真评估架构原型的实现过程，以对软件架构的开发期质量属性给出评价。有两种验证技术能够采用：原型技术和框架技术。

架构设计不能遗漏相当重要的非功能需求；架构设计必须驯服数量巨大且频繁变化的需求。架构设计涉及不一样方面的设计决策，软件架构师应当采用基于多视图的架构设计方法。架构设计的成果应及早验证，若是盲目假设架构方案是可行的，直到后期才发现问题，就会形成大规模返工乃至项目失败，所以软件架构师应注意尽早验证架构。

咱们不认为Coding和Designing是对立的。

把设计搞得玄而又玄的结果是，不少影响全局的设计决策本应由架构设计来完成的，却通通“漏”到了后边，最终到了大规模并行开发阶段才发现。这样一来，形成了“程序员碰头临时决定”的状况大量出现，软件质量必然降低，甚至还会致使项目失败。软件架构是团队开发的基础，软件架构必须设计到“能为开发人员提供足够的指导和限制”的程度。《人月神话》指出“软件的复杂度是根本属性，不是次要因素”。采用面向对象方法的“最重要的缘由”是它能够帮助咱们解决更复杂的问题，而不是更好的可重用性。面对一个复杂的问题，咱们如何分而治之？能够按照问题的深度进行分而治之或者按照问题的广度进行分而治之。接口和现实分离，就是“按问题的深度分而治之”一个很好的例子。将展示层、业务层和数据层分派给不一样小组承担，属于“按问题广度分而治之”的例子。

随着软件的规模和复杂度增长，算法和数据结构之外的设计问题就会出现：设计和制定系统总体结构将成为新的一类问题，这就是软件架构层次的设计。将设计分为架构设计和详细设计，是对“按问题深度分而治之”思想的运用：所谓架构设计，就是关于如何构建软件的一些最重要的设计决策，这些决策每每是围绕将系统分为哪些部分，各个部分之间如何交互展开的。而详细设计针对每一个部分的内部进行设计。软件架构设计应当解决的是全局性的、涉及不一样“局部”之间交互的设计问题，而不一样“局部”的设计由后续的详细设计负责。在软件架构所提供的“合做契约”的指导下，众多局部问题被很好地“按问题广度分而治之”了。这种先肯定软件架构，然后基于软件架构进行并行开发的作法，综合利用了上诉两种分而治之的方法，利用控制复杂性，提升开发效率。

面对“技术复杂性”和“管理复杂性”这样的双重困难，以架构为中心的开发方法是有效的途径：一方面，软件架构从大局着手，就技术方面的重大问题做出决策，构造一个具备必定抽象层次的解决方案，而不是将全部细节通通展开，从而有效地控制了“技术复杂性”。另外一方面，由于“架构中包含了关于各元素应如何彼此相关的信息”，从而能够把不一样的模块分配给不一样小组分头开发，而软件架构设计方案在这些小组中扮演“桥梁”和“合做契约”的做用。正由于软件架构是大规模开发的基础，因此架构中应包含软件系统的各元素如何彼此相关的设计决策；也正是由于软件架构包含了软件系统如何组织等关键决策，才能使得它可以成为大规模开发的基础。因而可知，软件架构为开展系统化的团队开发奠基了基础，为解决“管理复杂性”提供了有力的支持。

架构设计对软件的不一样部分的设计程度并非整齐划一的。因为项目的不一样、开发团队状况的不一样，软件架构的设计程度会有不一样；软件架构应当为开发人员提供足够的指导和限制。

所谓“高来高去式架构设计”，是指不能为开发人员提够足够的指导和限制的那种架构设计方案。高来高去式的架构设计大体有以下三种表现：一、缺失重要架构视图。为不一样的系统进行架构设计时，对不一样的架构视图的重视程度并不相同。“缺失重要架构视图”的一种表现是，认为软件架构设计彻底是用例驱动的，片面强调用例描述的功能需求。此时，架构设计对非功能需求关注不够，既没有深刻设计软件的运行架构，也没有深刻设计软件的开发架构。二、浅尝即止、不够深刻。架构方案过于笼统，基本还停留再概念性架构的层面，没有提够明确的技术蓝图。概念性架构对开发人员的指导和限制是不够的。架构设计阶段遗漏了全局性的设计决策，到了大规模开发实现阶段，这些设计决策每每被具体开发人员从局部视角考虑并肯定下来。三、名存实亡的分层架构。经过分层将软件系统模块化以后，就火烧眉毛地喊出“分层架构”的口号，对各层之间交互接口和交互机制的设计严重不足。仅仅用分层来进行职责划分，而没有规划层次之间的交互接口和交互机制的状况。缺失交互接口和交互机制的分层架构中，其实“层”已经退化成笼统意义的“职责模块”了。

高来高去式的架构自己没有错，它们每每属于概念性架构的范畴，它每每是按部就班地进行软件架构设计的良好起点。可是，若是停留在高来高去的架构设计上止步不前，并以之做为最终的架构设计方案，就会为后期开发埋下重大风险。

软件架构设计过程

通常来讲，软件开发过程包括5个阶段：概念化阶段、分析阶段、架构阶段、架构设计阶段、并行开发和测试阶段、验收与交付阶段。 概念阶段要解决项目的起源问题，主要针对项目目标、主要特性、功能范围和成功要素等进行构思并达成一致。分析阶段的目的是明确需求，并以《软件需求规格说明书》的形式记录下来。架构设计阶段要在较高的抽象层次上制定解决方案，即设计软件架构。并行开发和测试阶段动用的资源是最多的，在此阶段中，咱们以软件架构为基础，进行系统化的开发和测试。

架构设计的开展很是依赖其上游活动，这些上游活动包括需求分析和领域建模。领域建模的目的是透过问题领域的重重现象，捕捉其背后最为稳固的领域概念及这些概念之间的关系。在项目前期，所创建的领域模型将为全部团队成员之间、团队成员和客户之间的交流提够共同承认的语言核心。随着项目的进展，领域模型不断被精化，最终成为整个软件的问题领域层，该层决定了软件系统能力的范围。从项目前期伊始，软件架构师就应该是领域建模活动的领导者。

完成了上游活动，接下来要进行概念性架构设计。软件系统的规模越大、复杂度越高，进行概念性架构设计的好处就越明显。概念性架构的第一步是分析关键用例的用例规约，接下来明确架构模式，肯定交付机制，造成初步的概念性架构。概念性架构所关注的关键设计要素、交互机制、高层设计决策多与具体技术无关，而最终的软件架构设计方案必须和具体技术结合，为开发人员提供足够的指导和限制。

尽可能使架构设计策略做为软件架构设计过程的“一等公民”，这样才能更有效地指导软件架构师进行架构设计。

另外提一下领域模型建设。后面还会详细提到。领域模型凝聚了领域专家知识。问题领域可能很复杂，领域模型揭示了纷繁复杂的问题背后的结构。领域模型和软件需求不一样：领域模型是对问题领域“作透视”，从而揭示其内在结构；而软件需求是对问题领域“拍照片”，从而捕捉其外在功能。领域模型相对是稳定的，而软件需求是变化的，一个优秀的领域模型能够“容纳”必定程度的需求变化。领域模型是团队交流的基础，是全部团队成员所用语言的核心。

软件需求式委托方但愿软件系统达到的目标。软件需求不只包括功能需求，还包括质量属性和约束性属性。软件架构强调的是总体，而总体性的设计决策必须基于对需求的全面认识。另外，软件架构应该是稳定的。概念性架构是架构设计的初步成果。概念性架构也会肯定软件系统所采用的架构模式。对软件架构起关键做用的质量属性需求将在“质量属性分析”活动中进行。架构设计不断深刻的过程，也是领域模型不断精化的过程。随着用例分析的进行，不断有类的职责被肯定，做为类的方法被添加进来。最终的软件架构设计方案必须和具体技术结合，从而为开发人员提够足够的指导和限制。在设计软件的逻辑架构过程当中，领域模型将进一步精化，并成为软件逻辑架构的重要组成部分。

原文：http://www.uml.org.cn/zjjs/201307151.asp