Domain: 领域
Infrastructure: 基础架构
Requirement Pattern: 需求模式
Depends Upon: 依赖
图 3‑2领域，需求模式，以及基础架构之间的关系
需求模式可以自由使用其他领域中的基础架构。但是最好避免相互依赖，所以如果一个领域依赖另一个领域，那么后一个领域就不应该依赖前一个领域——如果可以避免的话。一个基础架构也可以依赖另一个基础架构。
基础架构概述应该说些什么呢？它的角色是指导和建议如何定义一个特定系统的基础架构的需求，提出需求需要覆盖的主题。最少，它应该陈述系统需要基础架构提供什么：它存在的目的是什么，它的主要功能。有些问题有很明显的替代解决方案，概述应该避免做判断。
每个基础架构概述分成下列小节：
1. 目的解释基础架构存在的理由，以及扮演的角色。 调用需求关于系统与基础架构如何交互的需求定义的建议——基础架构必须提供这些功能给系统——以及系统期望的其他的能力（比如访问控制）。需要的功能可以被看作是基础架构提供给调用者的接口。 实现需求为了使基础架构站得住脚所需要的一些特性的想法（例如，查询，维护和配置功能）。这些是比较简短的，只是在定义基础架构时提醒一些需要考虑的可能的主要功能域。
例如，对于报表基础架构，调用需求可能是很简单：只是让系统请求运行一个选定的报表的功能。而另一方面，实现需求则相当多，包括交付报告给用户的各种方式的复杂性，其他请求报告的方式，设计报告，等等。（这些主题在错误！未找到引用源。错误！未找到引用源。进一步讨论。）以建造房屋类推，我们需要的基础架构之一是电力供应。这种情况下，调用需求是每个屋子需要多少插座，实现需求处理的是看不见的部分，像是与电网的连线，遵守建筑质量法。
