架构模式也称为架构风格，它是适当地选取战术的结果，这些固定的结果（模式）在高层抽象层次上具有普遍实用性和复用性。通过架构模式，架构设计师可以借鉴和复用他人的经验，看看类似的问题别人是如何解决的。
但不要把模式看成是一个硬性的解决方法，它只是一种解决问题的思路 。MartinFowler 曾说： “ 模式和业务构件的区别就在于模式会引发你的思考 。”
1 演变交付生命周期
业界已开发出各种软件生命周期模型，其中把架构放在一个适当位置的模型中，典型的有演变交付生命周期模型。
在生命周期模型中，架构设计就是从初步的需求分析开始逐步进行循环迭代（图 1 中的反向箭头说明了这一点）。
即：一方面在了解系统需求前，不能开始设计架构；另一方面，刚开始进行设计架构时并不需要等到全部需求都收集到。架构是由 “ 架构驱动 ” 因素 “ 塑造 ” 的，架构因素是指少数关键的 、 优先级别最高的业务目标质量需求。架构由少数关键需求决定并在循环迭代中处于基本稳定状态，它作为演变的基础设施。
2 属性驱动设计法
上述模型强调先建立软件架构，再把架构作为骨架，在骨架上循环迭代，逐步长出有血有肉的系统之躯。属性驱动设计法（ Attribute-Driven Design ， ADD ）就是一种定义软件架构的方法，该方法将分解过程建立在软件必须满足的质量属性之上。
ADD 的输入为：功能需求（一般表示为用例） 、 限制条件和质量需求（一组特定于系统的质量场景）。
ADD 的步骤如下。
（1）选择要分解的模块
通常是整个系统，要求上述输入都是可获得的（限制条件 、 功能需求 、 质量需求）。从系统开始，然后分解为子系统，进一步将子系统分解为子模块。
（2）模块求精
从具体的质量场景和功能需求集合中选择架构驱动因素。并不是同等看待所有需求，而是在满足了最重要的需求的条件下，才满足不太重要的需求，即针对架构需求有优先级。选择满足架构驱动因素的架构模式，根据前面的战术创建（或选择）模式。其目标是建立一个由模块类型组成的总体架构模式。实例化模块并根据用例分配功能，使用多个视图进行表示。定义子模块的接口。验证用例和质量场景，并对其进行求精，使它们成为子模式的限制。
（3）重复
对需要进一步分解的每个模块重复上述步骤。
3 按架构组织开发团队
在架构的模块分解结构的最初几个层次相对稳定之后，就可以把这些模块分配给开发小组，其结果就是工作视图。像软件系统一样，开发小组也应该努力做到松耦合 、 高内聚。即每个模块都构成自己的小领域（专门知识或专门技术），并与其他模块的接口清晰，这样，不同的模块分到不同的开发小组中，就能减少各开发小组之间的沟通成本，而在各开发小组内部，由于是处理小领域的问题，容易建立起有效的沟通机制，如成员有这个小领域的背景知识（或培训获得） 、 共享决策信息。
同时，项目计划在架构确定之后可以结合分工进一步明细化，特别要规划好接口提供的时间点，保证项目开发的整体协调性。
4 开发骨架系统
演变交付生命周期模型中有两个循环，第一个循环是通过迭代的方式开发出软件架构，第二个循环是在架构的基础上通过迭代的方式开发出交付的最终版本。开发骨架系统就是第二个循环的第一步。这一步就是以架构为指导，开发一个可运行的原型（骨架系统）。在骨架系统开发过程中要注意对接口进行充分协商，避免先开发的部分强制随后部分满足其不合理的接口要求。骨架系统完成后，就可以在其上进行增量开发，直到软件开发完成。
5 利用商用构件进行开发
模式本来就是针对特定问题的解，因此，针对需求的特点，也可以选用相应的模式来设计架构，并利用对应于该模式的商用构件进行软件开发。例如可以使用 J2EE/EJB 进行开发面向对象的分布式系统。