软件架构设计

架构的概念

所谓软件架构就是针对于如何构建软件而做出的重要的设计决策，这些决策往往是围绕将系统分为哪些部分、各部分之间如何交互展开的。架构的是一个演进的过程，没有一成不变的架构，也没有一蹴而就的架构，架构需要根据业务的发展而进行相应的调整，我们应该更加关注架构演进的过程和原因，以及在当时背景下的做出的权衡和妥协。没有完美的架构，架构也没有一个标准的解决方案，因为面对不同的业务需求，面对不同的客观因素，有不同的架构设计方案，也就是有不同的设计决策。

 架构决策是分层次依次展开的，决策制定的顺序往往是先制定技术无关的决策，后制定技术相关的决策，后者在前者的指导下进行。

子系统、框架和架构

好的架构必须使每个关注点相互分离。把变化点错落有致地封装到软件系统的不同部分。通过关注点的分离来达到“系统中的一部分发生了变化，不会影响其他部分”的目标。可以通过如下的一下手段：

(1)通过职责划分来分离关注点。

(2)利用软件系统各部分的通用性的不同进行关注点分离。不同的通用程度意味着变化的可能性不同。

(3) 先考虑大粒度的子系统，而暂时忽略子系统是如何通过更小粒度的模块和类组成的。

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

当然，一个系统的粒度是具有相对性的，同一个软件单元，在不同场景下，我们会以不同的粒度看待它。所有的系统都有子系统，而所有系统都是更大系统的子系统。实践不同场景使得软件组成单元具有递归性。

框架是一种半成品,是可以通过某种回调机制进行扩展的软件系统或子系统的半成品。从某种程度上来说，是为了软件重用。软件重用本身又有一对内在的矛盾，即重用几率和重用价值，重用几率大小和重用带来的价值大小之间的矛盾。软件单元的粒度越大，可重用的几率就越小，但其重用所带来的价值就越大，相反，软件单元的粒度越小，可重用几率就越大，但其重用所带来的价值就越小。框架的智慧就在于此：为了追求重用所带来的价值最大化，将容易变化的的部分封装成扩展点，并辅以回调机制将它们纳入框架的控制范围之内。

框架是软件，而架构不是软件。框架是一种特殊的软件，它并不能提供完整的解决方案（准确说，是不提供业务应用的完整解决方案，而框架本身也是为解决某一类问题而出现的），而是为构建解决方案（这里的解决方案即是业务应用的解决方案）提供良好的基础。

框架中的服务可以被最终应用直接调用，而框架中的扩展点是供应用开发人员定制的“可变化点”。软件架构是关于软件如何设计的重要决策。软件架构决策涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。这些架构决策将体现在最终开发出的软件系统中。引入软件框架之后，整个开发过程变成了分两步走，而架构决策往往会体现在框架之中。软件架构是比具体代码高一个抽象层次的概念。架构势必被代码所体现和遵循，但任何一段具体的代码都代表不了架构。框架技术和架构技术的出现，都是为了解决软件系统日益复杂所带来的困难而采取“分而治之”的思想。先大局后局部，就出现了架构；先通用后专用，就出现了框架。架构是问题的抽象解决方案，它关注大局而忽略细节；框架是通用半成品，还必须根据具体需求进一步定制开发才能变成应用系统。当然，框架也有架构，而且很重要。框架和架构既有区别又有联系，前者是复合组件特例，后者是复合组件的大局设计。软件架构需要落地，需要了解细节，但也没有必要将所有设计决策事无巨细地落实，而是重点关注“重要决策”。软件架构设计的决策范围，应该着重放在“影响全局”的设计上，而不是所关注所有设计细节。

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

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

软件架构的作用

 软件架构对后期的软件维护，乃至改动力度比较大的软件升级都起着重要作用。因为软件架构给出了软件系统的一个全局的视角。对软件系统不断的修改会使系统架构慢慢变得混乱，因为业务的发展，是会慢慢腐蚀现有的系统架构的，所以架构需要根据业务的发展进行演进。

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

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

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

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

5利用迭代开发和增量交互

6提高质量：清晰的软件架构将各个模块的职责划分得有条不絮，每个模块都有清晰的接口，这相当于间接降低了开发难度。

软件架构从大局着手，就技术方面的重大问题做出决策，构造一个由粗粒度模块组成的解决方案，从而可以把不同模块分配给不同小组分头开发,从而可以把不同模块分配给不同小组分头开发。另一方面，软件架构设计方案规定了各模块之间如何交互的机制和接口，在开发小组之间起到“沟通桥梁”和“合作契约”的作用。

软件架构视图

软件架构视图是对与从某一视角或某一点上看到的系统所作出的简化描述，描述中涵盖了系统的某一特定方面，而省略了与此方面无关的实体。软件架构的每个视图分别关注不同的方面，针对不同的目标和用户。

最常用的两种架构视图：逻辑架构视图和物理架构视图

(1) 逻辑架构设计

将软件系统分解成不同的逻辑单元，并规定这些逻辑单元之间的交互接口和交互机制。三大核心任务：识别功能块；规划功能块的接口；明确功能块之间的使用关系和使用机制。逻辑架构的设计往往是从用例分析开始的。通过对每个关键用例的分析，从逻辑上将用例实现为一组功能块的特定组合，最后综合这些用例分析成果，得到整个软件系统的逻辑架构。

(2) 物理架构设计

反映出软件系统运行时的组织情况, 更重视软件系统运行时的动态结构，以及组成软件系统的目标程序如何部署到硬件上。交互机制，就是指不同软件单元之间的交互手段。交互机制可以是本地方法调用、基于RMI的远程方法调用、异步消息等。

软件的物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等需求。物理层作为组成软件系统的物理单元，最终又要映射到具体的硬件，这也是物理架构设计要考虑的，对于分布式软件系统的设计而言尤其不可或缺。

架构设计的5视图方法包括：逻辑架构、开发架构、运行架构、物理架构、数据架构。

(1)逻辑架构关注功能，它们可能是逻辑层、功能模块和类等。

(2)开发架构关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。

(3)运行架构关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。

(4)物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装和部署到物理机器上，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。

(5)数据架构关注持久化数据的存储方案，不仅包括实体及实体关系的数据存储格式，还可能包括数据传递、数据复制和数据同步等策略。

让关键需求决定架构。软件架构应当为开发人员提供足够的指导和限制。

软件架构设计过程

一般来说，软件开发过程包括5个阶段：概念化阶段、分析阶段、架构阶段、架构设计阶段、并行开发和测试阶段、验收与交付阶段。

(1)   概念阶段要解决项目的起源问题，主要针对项目目标、主要特性、功能范围和成功要素等进行构思并达成一致。

(2)    分析阶段的目的是明确需求，并以《软件需求规格说明书》的形式记录下来。

(3)    架构设计阶段要在较高的抽象层次上制定解决方案，即设计软件架构。

(4)    并行开发和测试阶段动用的资源是最多的，在此阶段中，我们以软件架构为基础，进行系统化的开发和测试。

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

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

领域模型凝聚了领域专家知识。问题领域可能很复杂，领域模型揭示了纷繁复杂的问题背后的结构。领域模型和软件需求不同：领域模型是对问题领域“做透视”，从而揭示其内在结构；而软件需求是对问题领域“拍照片”，从而捕捉其外在功能。领域模型相对是稳定的，而软件需求是变化的，一个优秀的领域模型可以“容纳”一定程度的需求变化。领域模型是团队交流的基础，是所有团队成员所用语言的核心。

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

需求分析致力于搞清楚软件系统要“做什么，系统分析已经开始涉及“怎么做”。系统分析是针对系统所要面临的问题，搜集相关的资料，以了解产生问题的原因所在，进而提出解决问题的方法与可行的逻辑方案，以满足系统的需求，实现预定的目标。

推荐的软件质量属性分类方式：

运行期质量属性：

性能、安全性、易用性、持续可用性、可伸缩性、互操作性、可靠性、鲁棒性（健壮性或容错性）。

开发期质量属性：

易理解性、可扩展性、可重用性、可测试性、可维护性、可移植性。

我们可以将运行期质量属性和功能性一起视为“软件的外部质量”，而将开发期质量属性视为“软件的内部质量”。无疑，软件的内部质量制约着软件的外部质量。

 

领域建模

分析的另一种重要产品是领域模型，其目标是使负责该系统基本行为的所有核心类可视。

软件的核心是它为用户解决领域相关问题的能力。 模型的选择会影响最终产生的系统的灵活性和可重用性。

由内而外早就软件。忽视了领域模型这个“内”，而仅重视编写程序这个“外”，多半是要出问题的。在对象开发过程中一个很重要的原则就是：要设计软件，使得软件的结构反映问题的结构。领域模型是对实际问题领域的抽象表示，它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。类图无疑是领域模型中使用最多的UML图，但有时状态图可以用来对业务领域对象的状态变化进行有效的补充说明。领域建模是公认的促使OO项目成功的最佳实践之一。

需求分析的两个困难：

1用户的参与不够，造成需求分析成果中假设的成分太多；

2问题领域太复杂时，需求分析的开展会遇到困难。

领域模型是对实际问题领域的抽象，它“穿透”用户想要的功能表象，专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。因此，开发方和用户在“领域模型”上达成的共识，往往比在“功能需求”上达成的共识“更深一级”，从而也更加稳固。“用户参与不够”其实是两个问题：用户参与不够多，或者用户参与不够深入。另外，领域建模对需求分析起着必要的支持作用。

领域模型是探索问题领域的工具，可以帮助我们探索和提炼问题领域知识。领域建模和需求分析活动是相互伴随、相互支持的。领域建模提供的词汇表应当成为所有团队成员所使用语言的核心，在需求活动以及其他活动中起到与团队交流基础的作用。另一方面，需求捕获和分析非常关键，因为不知道客户想要什么，就无法提供让客户满意的软件。

领域模型为需求定义提供了领域知识和领域词汇。软件界面的设计往往和领域模型关系密切，领域信息是所要展现内容中最重要的部分，界面结构必须和业务内容的结构相一致。领域模型是否合理将严重影响软件系统的可扩展性，模型的选择会影响最终产生的系统的灵活性和可重用性。领域模型经过精化之后会成为业务层的核心。领域模型是设计持久化数据模型的良好基础。

软件开发的“根本问题”，首当其冲的就是“软件的复杂性”。而运用面向对象的领域模型技术，可以帮助我们减轻复杂性的问题。领域模型本身将注意力始终保持在最为重要的业务概念及其关系上，使我们能够不断深入地、系统地整理对问题的认识。领域建模活动的结果是领域模型，但是由于问题领域的复杂性，领域模型不是一蹴而就的。在领域建模过程中，前期的成果往往很不完善，我们会不断基于现有的成果进行讨论、分析和完善。因此，领域建模的过程就是探索复杂问题的过程，领域模型决定了软件系统功能的范围。任何模型都是对现实世界的某种程度的抽象，领域模型也不例外。抽象意味着有目的性地忽略；而忽略哪些对象关系，保留哪些对象和关系，都和具体目的有关。领域模型还影响着软件系统的可扩展性。功能是软件系统能够完成的具体任务；而模型揭示了丰富多彩的功能需求背后的结构，是我们设法“驯服”复杂性时有了切中要害的“着力点”。功能需求记录了系统外在的、用户可感知的“应用列表”，但它们是易变的，当商业环境急剧变化的时候需求尤其易变；而领域模型揭示并模拟问题领域的内部结构，相当于对问题领域进行了一层抽象，良好的领域模型不仅支持现有功能需求的满足，还在一定程度上支持未来可能出现的新需求。