软件架构被描述为系统的组织，其中系统表示一组完成所定义功能的组件。
架构风格
架构 风格 ，也称为 架构模式 ，是塑造应用程序的一组原则。它根据结构组织的模式为系统家族定义了一个抽象框架。
架构风格负责 -
-
提供组件和连接器的词典，其中包含有关如何组合它们的规则。
-
通过为经常发生的问题提供解决方案来改进分区并允许重用设计。
-
描述配置组件集合（具有明确定义的接口、可重用和可替换的模块）和连接器（模块之间的通信链路）集合的特定方法。
|
为基于计算机的系统构建的软件表现出许多架构风格之一。每种样式描述一个系统类别，其中包含 -
-
一组组件类型，用于执行系统所需的功能。
-
一组连接器（子例程调用、远程过程调用、数据流和套接字），用于支持不同组件之间的通信、协调和协作。
-
语义约束，定义如何集成组件以形成系统。
-
指示其运行时相互关系的组件的拓扑布局。
|
通用架构设计
下表列出了可按其重点区域组织的体系结构样式 -
| 类别 |
架构设计 |
描述 |
| 通信 |
消息总线 |
规定使用可以使用一个或多个通信通道接收和发送消息的软件系统。 |
| 面向服务的体系结构 （SOA） |
定义使用协定和消息将功能公开和使用为服务的应用程序。 |
| 部署 |
客户端/服务器 |
将系统分成两个应用程序，其中客户端向服务器发出请求。 |
| 3 层或 N 层 |
将功能分成单独的段，每个段是位于物理上独立的计算机上的层。 |
| 域 |
领域驱动设计 |
专注于对业务域进行建模，并根据业务域中的实体定义业务对象。 |
| 结构 |
基于组件 |
将应用程序设计分解为可重用的功能或逻辑组件，以公开定义良好的通信接口。 |
| 分层的 |
将应用程序的关注点划分为堆叠组（层）。 |
| 面向对象 |
基于应用程序或系统对对象的责任划分，每个对象都包含与对象相关的数据和行为。 |
架构类型
从企业的角度来看，有四种类型的架构，这些架构统称为 企业架构 。
-
业务架构 - 定义企业内业务、治理、组织和关键业务流程的战略，并专注于业务流程的分析和设计。
-
应用程序 （软件）体系结构 − 作为各个应用程序系统、其交互以及它们与组织业务流程的关系的蓝图。
-
信息架构 − 定义逻辑和物理数据资产以及数据管理资源。
-
信息技术 （IT） 体系结构 − 定义构成组织整体信息系统的硬件和软件构建块。
|
架构设计流程
架构设计过程侧重于将系统分解为不同的组件及其交互，以满足功能和非功能需求。软件架构设计的关键输入是 -
-
分析任务产生的需求。
-
硬件架构（软件架构师反过来向系统架构师提供要求，系统架构师配置硬件架构）。
|
架构设计过程的结果或输出是 体系结构描述 。基本架构设计过程由以下步骤组成 -
了解问题
-
这是最关键的一步，因为它会影响随后的设计质量。
-
如果没有对问题的清晰理解，就不可能创建一个 有效的解决方案。
-
许多软件项目和产品被认为是失败的，因为它们实际上没有解决有效的业务问题或具有可识别的投资回报率（ROI）。
|
识别设计元素及其关系
-
在此阶段，构建用于定义系统边界和上下文的基线。
-
根据功能要求将系统分解为其主要组件。可以使用设计结构矩阵 （DSM） 对分解进行建模，该矩阵显示设计元素之间的依赖关系，而无需指定元素的粒度。
-
在此步骤中，体系结构的第一次验证是通过描述许多系统实例来完成的，此步骤称为基于功能的架构设计。
|
评估架构设计
-
每个质量属性都有一个估计值，因此为了收集定性度量或定量数据，对设计进行评估。
-
它涉及评估体系结构是否符合体系结构质量属性要求。
-
如果所有估计的质量属性都符合要求的标准，则架构设计过程完成。
-
如果没有，则进入软件架构设计的第三阶段：架构转换。如果观察到的质量属性不符合其要求，则必须创建新设计。
|
转变架构设计
-
此步骤在评估架构设计后执行。必须更改架构设计，直到完全满足质量属性要求。
-
它关注的是选择设计解决方案，以在保留域功能的同时提高质量属性。
-
通过应用设计运算符、样式或模式来转换设计。对于转换，采用现有设计并应用设计运算符，例如分解、复制、压缩、抽象和资源共享。
-
再次评估设计，并在必要时多次重复相同的过程，甚至递归执行。
-
转换（即质量属性优化解决方案）通常会改善一个或一些质量属性，而会对其他属性产生负面影响
|
关键架构原则
以下是设计架构时要考虑的关键原则 -
为改变而构建，而不是为持久而构建
考虑应用程序可能需要如何随时间变化以应对新的需求和挑战，并构建支持此需求的灵活性。
降低风险并建立模型进行分析
使用设计工具、可视化、建模系统（如 UML）来捕获需求和设计决策。还可以分析影响。不要将模型形式化到抑制轻松迭代和调整设计的能力的程度。
使用模型和可视化作为通信和协作工具
设计、决策和对设计的持续更改的有效沟通对于良好的架构至关重要。使用架构的模型、视图和其他可视化效果，与所有利益干系人有效地沟通和共享设计。这样可以快速传达设计更改。
识别并了解关键工程决策和最常犯错误的领域。投资在第一时间做出正确的关键决策，使设计更加灵活，不太可能因更改而中断。
使用增量和迭代方法
从基线架构开始，然后通过迭代测试改进候选架构以改进架构。通过多次通过迭代向设计添加细节，以获得大图或正确的图片，然后专注于细节。
关键设计原则
以下是要考虑的设计原则，以最大限度地降低成本、维护要求和最大限度地提高架构的可扩展性和可用性 -
关注点分离
将系统的组件划分为特定功能，以便组件功能之间没有重叠。这将提供高内聚力和低耦合。这种方法避免了系统组件之间的相互依赖性，这有助于轻松维护系统。
单一责任原则
系统的每个模块都应该有一个特定的职责，这有助于用户清楚地了解系统。它还应该有助于将组件与其他组件集成。
最小知识原则
任何组件或对象都不应了解其他组件的内部详细信息。此方法避免了相互依赖性，并有助于可维护性。
最小化前期大型设计
如果应用程序的要求不明确，请尽量减少前期的大型设计。如果有可能修改需求，则避免对整个系统进行大型设计。
不要重复该功能
“不重复”功能指定不应重复组件的功能，因此一段代码应仅在一个组件中实现。应用程序中的功能重复可能会使实施更改变得困难，降低清晰度并引入潜在的不一致。
重用功能时更喜欢组合而不是继承
继承在子类和父类之间创建依赖关系，因此它阻止了子类的自由使用。相比之下，组合提供了很大的自由度并减少了继承层次结构。
识别组件并将其分组到逻辑层中
标识组件和系统中满足要求所需的关注区域。然后将这些相关组件分组到一个逻辑层中，这将有助于用户在高层次上理解系统的结构。避免在同一层中混合使用不同类型关注点的组件。
定义层之间的通信协议
了解组件如何相互通信，这需要全面了解部署方案和生产环境。
定义图层的数据格式
各种组件将通过数据格式相互交互。不要混合使用数据格式，以便应用程序易于实现、扩展和维护。尝试保持层的数据格式相同，以便各种组件在相互通信时不需要对数据进行编码/解码。它减少了处理开销。
系统服务组件应该是抽象的
与安全、通信或系统服务（如日志记录、分析和配置）相关的代码应在单独的组件中抽象。不要将此代码与业务逻辑混合，因为扩展和维护它很容易。
设计异常和异常处理机制
提前定义异常，有助于组件以优雅的方式管理错误或不需要的情况。整个系统的异常管理将是相同的。
命名约定
应提前定义命名约定。它们提供了一个一致的模型，可帮助用户轻松理解系统。团队成员更容易验证其他人编写的代码，因此将提高可维护性。
|
