关键原则

软件架构被描述为系统的组织，其中系统代表一组完成定义功能的组件。

架构风格

架构风格，也称为架构模式，是一组塑造应用程序的原则。它根据结构组织模式为系统系列定义一个抽象框架。

架构风格负责 −

• 提供组件和连接器词汇表，并说明如何组合它们。

• 通过提供经常出现的问题的解决方案，改进分区并允许重用设计。

• 描述配置组件集合（具有明确定义的接口、可重用和可替换的模块）和连接器（模块之间的通信链接）的特定方法。

为基于计算机的系统构建的软件展现出众多架构风格之一。每种风格都描述了一个包含 − 的系统类别。

• 一组执行系统所需功能的组件类型。

• 一组连接器（子例程调用、远程过程调用、数据流和套接字），用于实现不同组件之间的通信、协调和合作。

• 定义如何集成组件以形成系统的语义约束。

• 组件的拓扑布局，指示它们的运行时相互关系。

常见的架构设计

下表列出了可按其主要关注领域组织的架构风格 −

架构类型

从企业的角度来看，架构有四种类型，这些架构统称为企业架构。

• 业务架构 − 定义企业内的业务、治理、组织和关键业务流程的策略，并专注于业务流程的分析和设计。

• 应用程序（软件）架构 − 用作各个应用程序系统、它们的交互以及它们与组织业务流程的关系的蓝图。

• 信息架构 − 定义逻辑和物理数据资产以及数据管理资源。

• 信息技术 (IT) 架构 −定义构成组织整体信息系统的硬件和软件构建块。

架构设计过程

架构设计过程侧重于将系统分解为不同的组件及其交互以满足功能和非功能需求。软件架构设计的关键输入是−

• 分析任务产生的需求。

• 硬件架构（软件架构师反过来向系统架构师提供需求，系统架构师配置硬件架构）。

架构设计过程的结果或输出是架构描述。基本架构设计过程由以下步骤组成 −

了解问题

• 这是最关键的一步，因为它会影响后续设计的质量。

• 如果不清楚问题，就不可能创建有效的解决方案。

• 许多软件项目和产品被视为失败，因为它们实际上并未解决有效的业务问题或具有可识别的投资回报率 (ROI)。

确定设计元素及其关系

• 在此阶段，建立定义系统边界和上下文的基线。

• 根据功能需求将系统分解为其主要组件。可以使用设计结构矩阵 (DSM) 对分解进行建模，该矩阵显示设计元素之间的依赖关系，而无需指定元素的粒度。

• 在此步骤中，通过描述多个系统实例来完成架构的首次验证，此步骤称为基于功能的架构设计。

评估架构设计

• 每个质量属性都有一个估计值，因此，为了收集定性指标或定量数据，需要对设计进行评估。

• 它涉及评估架构是否符合架构质量属性要求。

• 如果所有估计的质量属性都符合要求的标准，则架构设计过程就完成了。

• 如果不是，则进入软件架构设计的第三阶段：架构转换。如果观察到的质量属性不符合其要求，则必须创建新的设计。

转换架构设计

• 此步骤在评估架构设计后执行。必须更改架构设计，直到它完全满足质量属性要求为止。

• 它涉及选择设计解决方案以改进质量属性，同时保留域功能。

• 通过应用设计运算符、样式或模式来转换设计。对于转换，采用现有设计并应用设计操作符，例如分解、复制、压缩、抽象和资源共享。

• 再次评估设计，如有必要，重复相同的过程多次，甚至递归执行。

• 转换（即质量属性优化解决方案）通常会改善一个或多个质量属性，同时对其他属性产生负面影响

关键架构原则

以下是在设计架构时要考虑的关键原则 −

构建以改变为目的，而不是构建以持久为目的

考虑应用程序可能需要如何随着时间的推移而改变以应对新的要求和挑战，并建立灵活性来支持这一点。

降低风险并建立模型进行分析

使用设计工具、可视化、建模系统（如 UML）来捕获需求和设计决策。还可以分析影响。不要将模型形式化到抑制迭代和轻松调整设计能力的程度。

使用模型和可视化作为沟通和协作工具

高效地传达设计、决策和对设计的持续更改对于良好的架构至关重要。使用架构的模型、视图和其他可视化与所有利益相关者高效地沟通和共享设计。这可以快速传达对设计的更改。

识别和理解关键的工程决策和最常犯错误的领域。投资于第一次就做出正确的关键决策，以使设计更加灵活，更不容易因变化而受到破坏。

使用增量和迭代方法

从基线架构开始，然后通过迭代测试改进候选架构以改进架构。通过多次迭代向设计添加细节以获得全局或正确的图景，然后专注于细节。

关键设计原则

以下是需要考虑的设计原则，以最大限度地降低成本、维护要求，并最大限度地提高架构的可扩展性和可用性−

关注点分离

将系统的组件划分为特定功能，以便组件功能之间没有重叠。这将提供高内聚性和低耦合。这种方法避免了系统组件之间的相互依赖，有助于轻松维护系统。

单一职责原则

系统的每个模块都应该有一个特定的职责，这有助于用户清楚地了解系统。它还应有助于组件与其他组件的集成。

最少知识原则

任何组件或对象都不应该了解其他组件的内部细节。这种方法避免了相互依赖并有助于可维护性。

尽量减少前期的大型设计

如果应用程序的要求不明确，请尽量减少前期的大型设计。如果有可能修改需求，则避免对整个系统进行大型设计。

不要重复功能

不要重复功能指定组件的功能不应重复，因此一段代码应仅在一个组件中实现。应用程序内的重复功能会使实施更改变得困难，降低清晰度并引入潜在的不一致。

在重用功能时，优先使用组合而不是继承

继承在子类和父类之间创建依赖关系，因此会阻止子类的自由使用。相反，组合提供了很大的自由度并减少了继承层次结构。

识别组件并将它们分组到逻辑层中

识别系统中需要满足要求的组件和关注领域。然后将这些相关组件分组到逻辑层中，这将有助于用户从高层次上理解系统的结构。避免在同一层中混合不同类型的组件。

定义层之间的通信协议

了解组件如何相互通信，这需要对部署场景和生产环境有全面的了解。

定义层的数据格式

各种组件将通过数据格式相互交互。不要混合数据格式，以便应用程序易于实现、扩展和维护。尽量保持层的数据格式相同，以便各种组件在相互通信时无需对数据进行编码/解码。它减少了处理开销。

系统服务组件应该是抽象的

与安全、通信或系统服务（如日志记录、分析和配置）相关的代码应该在单独的组件中抽象出来。不要将此代码与业务逻辑混合，因为这样很容易扩展设计和维护。

设计异常和异常处理机制

提前定义异常，有助于组件以优雅的方式管理错误或不必要的情况。整个系统的异常管理都是相同的。

命名约定

命名约定应提前定义。它们提供一致的模型，帮助用户轻松理解系统。团队成员更容易验证他人编写的代码，从而提高可维护性。