类似JDepend的工具，特征如下： 1）、根据您对系统架构约束的定义，时刻监视真实系统中的不一致，在每次构建（将来，我会考虑改为每次编译时）时直接告诉你问题的细节，大大提高你定位问题的效率； 2）、您可以只定义"允许"的规则，也可以只定义"不允许"的规则，是的，因为我发现别的工具只能定义架构“是什么”约束，而不能设定“不是什么”约束，所以才有了这样的改进，对了，这些规则可以是组件级别的，也可以是包级别的，而不少类似工具只是简单地对自然包进行分析，事实上，有些自然包的划分仅仅是出于概念的清晰性而建立的，并不是出于设计影响的目的，对于这样的包，我们难以对它有太多苛求，只有在"组件"级别上，才有必要认真考虑它们之间依赖的设计影响，所以，JDM的不同之处就在于它更人性化地把管理粒度的重点从包转移到了组件—— 一个可以自由定义大小的概念上，使得您可以将概念划分和设计影响“解耦合”。 3）、它很人性化，您可以自定义各种规则不符合到什么程度才是您不可接受的，哦，这也是很多类似工具做得不够的地方，我不用再被迫一刀切地僵化地使用工具了，我可以很方便地定义不同局部的质量要求，可以方便地定义它们不同的警报级别，还可以定义不同问题输出信息的程度——您可不想被一大堆无用的信息淹没，对吧？ 4）、它确实有点power，真的，我自己以前用的工具只会告诉我结果，而难以把问题的究竟给我解释清楚，现在它不仅会告诉我哪里出问题了，还能给出内部的详细分析信息，例如：出现了组件之间的循环依赖，它不是简单地告诉我哪些组件存在循环依赖，而是会告诉我这些循环依赖路径有几条，分别是什么，还会告诉我一个环中的每段组件依赖内部是由哪些包依赖甚至类依赖构成的，这些详细信息能够大大提高你定位问题的效率，您可以将它直接作为单元测试运行，如果将它加入持续集成冒烟测试，失败的架构验证能够使得构建失败，保证不符合质量的设计不会被打包和发布；

/* * 原始需求背景： * 网宿CDN要按月收取客户的服务费用，根据流量的大小、 * 服务的类型等，收取不同的费用，收费规则如下： * web应用：1000元/M * 流媒体应用：1000元/M*0.7 * 下载应用：1000元/M*0.5 * 月末打印报表时，要罗列每个用户每个频道的费用、客户总费用， * 还要打印该客户的重要性指数,重要性指数=网页流/100+下载流量/600； * * 需求变更场景： * 系统已经开发出来了，接下来，运维部门现在希望对系统做一点修改， * 首先，他们希望能够输出xml，这样可以被其它系统读取和处理，但是， * 这段代码根本不可能在输出xml的代码中复用report()的任何行为，唯一 * 可以做的就是重写一个xmlReport()，大量重复report()中的行为，当然， * 现在这个修改还不费劲，拷贝一份report()直接修改就是了。 * 不久，成本中心又要求修改计费规则，于是我们必须同时修改xmlReport() * 和report()，并确保其一致性，当后续还要修改的时候，复制-黏贴的问题就 * 浮现出来了，这造成了潜在的威胁。 * 再后来，客服部门希望修改服务类型和用户重要性指数的计算规则， * 但还没决定怎么改，他们设想了几种方案，这些方案会影响用户的计费规则， * 程序必须再次同时修改xmlReport()和report()，随着各种规则变得越来越复杂， * 适当的修改点越 来越难找，不犯错误的机会越来越少。 * 现在，我们运用所学的OO原则和方法开始进行改写吧。 */