我在曾经从事的很多软件开发项目中观察到，软件开发中一直存在这样一种现象：您实际拥有的架构往往与想象中的不同。

　　通过分析代码的度量报告，比如由 JDepend 工具生成的报告，您可以有效地判定代码是否实现了确定的架构。有些团队对代码做反向设计，得到对应的 UML 图表，也能够达到上述效果，还有一些团队甚至在编程时使用 IDE 生成相同的工件 —— 即实时反向设计。可是，所有的这些方法都还是反应式(reactive)的。您必须手工审视并分析报告或图表，确定架构是否存在偏离，而有时这种偏离可能很久之后才被发现。

　　设想每当某部分代码与期望的 架构有所违背时，您就得到一个提示 —— 比如一个 Ant 构建脚本失败 —— 如清单 1 所示：

　　清单 1. 违背架构导致构建失败

　　本文所提及的技术能够使您通过实现构建自动化主动分析软件架构。除此之外，本文的示例还演示了如何基于规则触发构建过程失败，您可以使用 JDepend 的 API 和 JUnit 定义这些规则。

　　当然，最重要的是，通过构建自动化，您和您的团队能够在开发周期的前期 发现源代码与确定架构之间的偏离。这就是我所说的掌控架构!

　　反应式地设置开发阶段

　　图 1 说明了在构建 Web 应用时一种常见的架构模式。 presentation 层(代表一组相关的包)依赖于 controller 层，controller 层依赖于 domain 和 business 层，最后，business 层依赖于 data 和 domain 层。

图 1. 典型 web 应用的一个架构分层图

　　至此，一切都很好，是吗?但是，我很确定您以前遇到类似的情形，那些常见的最佳实践规则会在日常的软件开发中被遗忘。事实上，这一点很容易(也很快)就会发生。