《软件架构设计》学习笔记&摘录（三）

成功的架构设计

好的架构应当具有如下品质：

• 良好的模块化。每个模块职责明晰，模块之间松耦合，模块内部高聚合并合理地实现了信息隐藏。
• 适应功能需求的变化，适应技术的变化。应该保持应用相关模块和领域通用模块的分离，技术平台相关模块和独立于具体技术的模块相分离，从而达到“隔离变化”的效果。
• 对系统的动态运行有良好的规划。
• 对数据的良好规划。
• 明确、灵活的部署规则。

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

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

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

       软件架构设计强调的是整体，而整体性的设计决策必须基于对需求的全面认识。全面认识需求，是生产出高质量软件所必须的“第一项修炼”。要全面认识需求，我们必须从不同级别来考察需求：组织级、用户级、开发级，还要对每个级别考虑不同类型的需求：功能需求、质量属性、约束。全面认识需求还有一层含义，那就是应当在深思熟虑之后作出适合的需求权衡和取舍。一方面，众多质量属性需求之间往往会有冲突，我们必须权衡。另一方面，如果通过复杂设计所支持的变化根本不会发生，那么这种过度设计就造成了资源的浪费并增加了开发的难度。

       让关键需求决定架构。功能需求数量众多，应该控制架构设计时需要详细分析的用例个数；另一方面，不同质量属性之间往往具有相互制约性，于是我们自然应该权衡哪一部分质量属性是架构设计的重大目标。需求来自与实践需要，而实践是发展的，所以“确定的需求”只是相对的。我们一般在项目的业务目标以核心需求达成共识之后就开始架构设计，关键需求决定架构的策略非常适合。

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

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

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

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

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

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

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

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

       高来高去式的架构本身没有错，它们往往属于概念性架构的范畴，它往往是循序渐进地进行软件架构设计的良好起点。但是，如果停留在高来高去的架构设计上止步不前，并以之作为最终的架构设计方案，就会为后期开发埋下重大风险。

 

软件架构设计过程

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

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

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

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

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

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

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