Home

  您相信架构文档上那些漂亮的结构图就是团队最终实际开发出来的系统结构吗？随着需求的不断变更、系统的不断演化，您如何保证架构的质量不会逐步退化？您如何知道实际的架构都一直很好地遵从经典的组件（包）的依赖原则（无环依赖、抽象稳定等价、朝向稳定依赖等）？难道要不停地code review？很多有问题的依赖关系的引入总是那么让人难以察觉，而当您有朝一日发现它的时候，它就如同已经深埋入地基中的石头一般难以撬动，如果因此而不对它进行重构，就只能采取一些退而求其次的权宜之计，这很可能进一步提高系统将来的维护成本，您一定需要一种工具能够尽早地帮助你发现这些非常容易引入却很不容易及时察觉的架构性的“大”问题，java-dependence-manager（JDM）就是这样一种好东西，它完全根据您所定义的架构约束规则来监控正在开发中的系统，在出现问题的同时发现问题，这时候，你所付出的代价才可能是最小的，仅就当前版本而言，它已经做到了：
   1）、根据您对系统架构约束的定义，时刻监视真实系统中出现的违例约束，在每次构建（将来，我会考虑改为每次编译时）时直接告诉你违例的组件（包）依赖出现在具体哪两个类之间，它们的依赖类型是调用、参数还是字段，大大提高你定位问题的效率；
   2）、您可以只定义“允许”的依赖，也可以只定义“不允许”的依赖，这些关系可以是组件级别的，也可以是包级别的，我看到多数类似工具往往直接根据自然包的划分来分析依赖关系，事实上，有些自然包仅仅是出于概念划分的清晰性而建立的，并不是出于设计影响的目的，对于这样的包，我个人不认为要强求它们必须多么符合经典的包划分理论，如果将包再次封装成“组件”后，就有必要认真考虑它们之间依赖的设计影响了，所以，JDM的不同之处就在于它更人性化地把管理粒度的重点从包转移到了组件————一个可以自由定义大小的概念上，使得您不必将包划分理论强加于为概念而划分的包之上，当然，您要这样它也是可以的。
   3）、它根据经典的包依赖原则自动化地帮你度量系统各个部分的符合程度，您可以自定义可以容忍的不符合程度，超过时，它不仅会告诉你哪里出问题了，还能给出内部的详细分析信息，例如：出现了组件之间的循环依赖，它不是简单地告诉你哪些组件存在循环依赖，而是会告诉你这些循环依赖路径有几条，分别是什么，还会告诉你一个环中的每段组件依赖内部是由哪些包依赖甚至类依赖构成的，这些详细信息能够大大提高你定位问题的效率；
   JDM的使用并不复杂，它需要通过XML配置文件来获取你对系统约束的定义，而这些配置文件的写法，在指南中有详细的例子，然后，您只需要在测试脚本中写一段简单的调用，传入类文件的文件夹路径或jar文件路径就可以了，所以，它可以直接作为单元测试运行，如果将它加入持续集成冒烟测试，失败的架构验证能够使得构建失败，保证不符合质量的设计不会被打包和发布。将来，JDM会有Eclipse插件版本和Mave的插件版本，并且，在Eclipse中将以图形化的方式进行架构约束的定义和分析结果的展现，每次重新编译时，直接在IDE中提示违例的依赖，呵呵，这是后话，希望这个版本的JDM能有更多的人试用，多多提供宝贵意见，为下一个版本的到来打好基础，谢谢各位！