引言

开发人员在没有正式架构的情况下就开始编写应用程序代码的情况非常普遍。如果没有清晰明确的架构，大多数开发人员和架构师都会采用事实上的标准分层架构模式（也称为n层架构），通过将源代码模块分离成包来创建隐式层。不幸的是，这种做法通常会导致一堆缺乏明确角色、职责和相互关系的无序源代码模块。这通常被称为大泥球（big ball of mud） 架构反模式。

缺乏正式架构的应用程序通常耦合性强、脆弱、难以变更，并且缺乏清晰的愿景或方向。因此，如果不完全了解系统中每个组件和模块的内部运作方式，就很难确定应用程序的架构特性。关于部署和维护的基本问题也难以回答：架构是否可扩展？应用程序的性能特征是什么？应用程序对变更的响应能力如何？应用程序的部署特性是什么？架构的响应速度如何？

架构模式有助于定义应用程序的基本特征和行为。例如，某些架构模式天然适用于高度可扩展的应用程序，而另一些架构模式则天然适用于高度敏捷的应用程序。了解每种架构模式的特征、优势和劣势至关重要，以便选择最符合您特定业务需求和目标的模式。

作为架构师，您必须始终为您的架构决策提供合理的依据，尤其是在选择特定架构模式或方法时。本报告旨在为您提供足够的信息，帮助您做出并论证该决策。