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

建筑风格

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

建筑风格负责-

• 为组件和连接器的词典提供如何组合的规则。

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

• 描述配置组件(具有良好定义的接口，可重用和可替换的模块)和连接器(模块之间的通信链接)的集合的特定方式。

为基于计算机的系统而构建的软件表现出许多体系结构样式之一。每种样式都描述一个系统类别，其中包括-

• 一组由系统执行所需函数的组件类型。

• 一组连接器(子例程调用，远程过程调用，数据流和套接字)，使不同组件之间能够进行通信，协调和协作。

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

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

普通建筑设计

下表列出了可以按其主要关注领域进行组织的建筑风格-

建筑类型

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

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

• 应用程序(软件)架构-用作各个应用程序系统，它们之间的交互以及与组织业务流程的关系的蓝图。

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

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

建筑设计过程

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

• 由分析任务产生的需求。

• 硬件架构(软件架构师又向配置硬件架构的系统架构师提供要求)。

体系结构设计过程的结果或输出是体系结构描述。基本架构设计过程包括以下步骤-

了解问题

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

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

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

识别设计元素及其关系

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

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

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

评估架构设计

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

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

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

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

改变建筑设计

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

• 它与选择设计解决方案有关，以在保留域功能的同时改善质量属性。

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

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

• 转换(即质量属性优化解决方案)通常会改善一个或某些质量属性，而对其他质量属性产生负面影响

关键架构原则

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

为了改变而不是为了持久

考虑一下应用程序可能需要随着时间的变化而变化，以解决新的要求和挑战，并建立支持它的灵活性。

降低风险并进行模型分析

使用设计工具，可视化效果，建模系统(例如UML)来捕获需求和设计决策。影响也可以分析。不要对模型进行形式化，以免抑制其轻易迭代和修改设计的能力。

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

设计，决策和设计的有效更改之间的有效沟通对于良好的体系结构至关重要。使用模型，视图和体系结构的其他可视化效果与所有涉众有效地交流和共享设计。这样可以快速传达设计变更。

识别并了解关键的工程决策和最容易出错的领域。在第一时间投资于正确的关键决策，以使设计更加灵活，并且不会因更改而被破坏。

使用增量迭代方法

从基线架构开始，然后通过迭代测试来改进候选架构以改进架构。通过多次遍历将迭代细节添加到设计中，以获取大图或正确的图片，然后专注于细节。

关键设计原则

以下是在最大程度地降低成本，维护要求并最大程度地提高体系结构的可扩展性和可用性时应考虑的设计原则-

关注点分离

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

单一责任原则

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

最少知识原理

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

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

如果应用程序的需求不清楚，则最大程度地减少前期的大型设计。如果有可能修改需求，则避免对整个系统进行大型设计。

不要重复功能

不重复功能表示不应重复组件的功能，因此仅应在一个组件中实现一段代码。应用程序内功能的重复会使其难以实施更改，降低清晰度并引入潜在的不一致之处。

重用功能时要优先考虑组合而不是继承

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

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

系统中满足要求所需的标识组件和关注区域。然后将这些相关组件分组在一个逻辑层中，这将帮助用户从更高层次上了解系统的结构。避免在同一层中混合不同类型关注点的组件。

定义层之间的通信协议

了解组件之间如何通信，这需要对部署方案和生产环境有完整的了解。

定义图层的数据格式

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

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

与安全性，通信或系统服务(例如日志记录，概要文件和配置)相关的代码应在单独的组件中抽象化。不要将此代码与业务逻辑混合使用，因为扩展设计和维护很容易。

设计异常和异常处理机制

预先定义异常，有助于组件以优雅的方式管理错误或意外情况。整个系统中的异常管理都是相同的。

命名约定

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