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