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

架构风格

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

架构风格负责 -

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

通用架构设计

下表列出了可按其重点区域组织的体系结构样式 -

架构类型

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

架构设计流程

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

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

了解问题

识别设计元素及其关系

评估架构设计

转变架构设计

关键架构原则

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

为改变而构建，而不是为持久而构建

考虑应用程序可能需要如何随时间变化以应对新的需求和挑战，并构建支持此需求的灵活性。

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

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

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

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

识别并了解关键工程决策和最常犯错误的领域。投资在第一时间做出正确的关键决策，使设计更加灵活，不太可能因更改而中断。

使用增量和迭代方法

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

关键设计原则

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

关注点分离

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

单一责任原则

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

最小知识原则

任何组件或对象都不应了解其他组件的内部详细信息。此方法避免了相互依赖性，并有助于可维护性。

最小化前期大型设计

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

不要重复该功能

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

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

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

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

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

定义层之间的通信协议

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

定义图层的数据格式

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

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

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

设计异常和异常处理机制

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

命名约定

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