构架模式是解决复杂构架问题的现成形式。构架框架或构架基础设施（中间件）是可以在其上构建某种构架的构件集。许多主要的构架困难应在框架或基础设施中进行解决，而且通常针对于特定的领域：命令和控制、MIS、控制系统等等。
根据构架模式最适用的系统的特征将其分类，其中一个类别处理更普遍的结构问题。下表显示了【BUS96】中所提供的类别和这些类别所包含的模式。类别模式结构层管道和过滤器黑板分布式系统代理交互系统模型-视图-控制器表示-抽象-控制自适应系统反射微核为阐明其含义，下面将详述其中的两个。完整说明请参见【BUS96】。
模式以下列广泛使用的形式来表示：模式名、环境、问题、影响，描述应考虑的不同问题方面、解决方案、基本原理、结果环境、示例、模式名层、环境、需要进行结构分解的大系统、问题必须处理不同抽象层次的问题的系统。例如：硬件控制问题、常见服务问题和针对于不同领域的问题。最好不要编写垂直构件来处理所有抽象层次的问题。否则要在不同的构件中多次处理相同的问题（可能会不一致）。
影响：系统的某些部分应当是可替换的；构件中的变化不应波动；相似的责任应归为一组；构件大小--复杂构件可能要进行分解
解决办法：将系统分成构件组，并使构件组形成层叠结构。使上层只使用下层（决不使用上层）提供的服务。尽量不使用非紧邻下层提供的服务（不跳层使用服务，除非中间层只添加通过构件）。
示例：
1.通用层
严格的分层构架规定设计元素（类、构件、包、子系统）只能使用下层提供的服务，服务可以包括事件处理、错误处理、数据库访问等等。相对于记录在底层的原始操作系统级调用，它包括更明显的机制。
2.业务系统层
右图显示了另一个分层示例，其中有垂直特定应用层、水平层和基础设施层。注意：此处的目标是采用非常短的业务“烟囱”并实现各种应用程序间的通用性。否则，就可能有多个人解决同一问题，从而导致潜在的分歧。
环境：没有解决问题的确定方法（算法）或方法不可行的领域。例如AI系统、语音识别和监视系统。
问题：多个问题解决顾问（知识顾问）必须通过协作来解决他们无法单独解决的问题。各顾问的工作结果必须可以供所有其他顾问访问，使他们可以评估自己是否可以参与解决方案的查找并发布其工作结果。
影响：知识顾问参与解决问题的顺序不是确定的，这可能取决于问题解决策略；不同顾问的输入（结果或部分解决方案）可能有不同的表示方式；各顾问并不直接知道对方的存在，但可以评估对方发布的工作
解决办法：多名知识顾问都可访问一个称为“黑板”的共享数据库。黑板提供监测和更新其内容的接口。控制模块/对象激活遵循某种策略的顾问。激活后，顾问查看黑板，以确定它是否能参与解决问题。如果顾问决定它可以参与，控制对象就可以允许顾问将其部分（或最终）解决方案放置于黑板上。
示例：
以上显示了使用UML建模的结构或静态视图。它将成为参数化协作的一部分，然后会绑定到实参上对模式进行实例化。
构架风格
软件构架（或仅是构架视图）可以具有名为构架风格的属性，该属性减少了可选的形式，并使构架具有一定程度的一致性。样式可以通过一组模式或通过选择特定构件或连接器作为基本构件来定义。对给定系统，某些样式可作为构架描述的一部分记录在构架风格指南（RationalUnifiedProcess中设计指南文档的一部分）中。样式在构架的可理解性与完整性方面起着主要的作用。