关键原则

---

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

建筑风格

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

建筑风格负责 -

• 提供组件和连接器的词典以及如何组合它们的规则。

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

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

为基于计算机的系统构建的软件表现出多种架构风格之一。每种风格都描述了一个系统类别，其中包括 -

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

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

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

• 组件的拓扑布局表明它们运行时的相互关系。

通用建筑设计

下表列出了可以按其重点关注领域组织的架构风格 -

建筑类型

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

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

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

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

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

架构设计流程

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

• 分析任务产生的需求。

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

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

了解问题

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

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

• 许多软件项目和产品被认为是失败的，因为它们实际上没有解决有效的业务问题或没有可识别的投资回报（ROI）。

确定设计元素及其关系

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

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

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

评估架构设计

• 每个质量属性都会给出一个估计值，以便收集定性测量或定量数据，对设计进行评估。

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

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

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

转变架构设计

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

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

• 通过应用设计运算符、样式或模式来转换设计。改造时，采用现有设计，应用分解、复制、压缩、抽象、资源共享等设计算子。

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

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

关键架构原则

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

构建变革而不是构建基业长青

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

降低风险和模型进行分析

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

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

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

识别并了解关键的工程决策以及最常犯错误的领域。投资于第一次就做出正确的关键决策，以使设计更加灵活，并且不太可能因变化而被破坏。

使用增量和迭代方法

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

主要设计原则

以下是最小化成本、维护要求以及最大化架构的可扩展性和可用性时要考虑的设计原则 -

关注点分离

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

单一责任原则

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

最少知识原则

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

最大限度地减少前期大型设计

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

不要重复功能

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

在重用功能时更喜欢组合而不是继承

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

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

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

定义层间通信协议

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

定义图层的数据格式

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

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

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

设计异常及异常处理机制

提前定义异常可以帮助组件以优雅的方式管理错误或不需要的情况。整个系统的异常管理将是相同的。

命名约定

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