资 源 简 介
简介：
您相信架构文档上那些漂亮的结构图就是团队最终实际开发出来的系统结构吗？
需求的不断变更、系统的不断演化，您如何保证架构的质量不会逐步退化？
您如何知道实际的架构都一直很好地遵从经典的组件（包）的依赖原则（无环依赖、抽象稳定等价、朝向稳定依赖等）？
很多有问题的依赖关系的引入总是那么让人难以察觉，除非你有办法不断地code review——这显然成本太高，将来，这些问题如同悄悄潜入并深埋入地基中的石头一般难以撬动，我很相信这句话：“一个潜伏已久的小问题，比一个马上发现的大问题更严重”，而架构性的问题，本身通常就不会是什么小问题，不是吗？您一定需要一种工具能够尽早地帮助你发现这些非常容易潜入却难以察觉的"大"问题，java-dependence-manager（JDM）就是这样一种好东西，它能够：
1）、根据您对系统架构约束的定义，时刻监视真实系统中的不一致，在每次构建（将来，我会考虑改为每次编译时）时直接告诉你问题的细节，大大提高你定位问题的效率；
2）、您可以只定义"允许"的规则，也可以只定义"不允许"的规则，是的，因为我发现别的工具只能定义架构“是什么”约束，而不能设定“不是什么”约束，所以才有了这样的改进，对了，这些规则可以是组件级别的，也可以是包级别的，而不少类似工具只是简单地对自然包进行分析，事实上，有些自然包的划分仅仅是出于概念的清晰性而建立的，并不是出于设计影响的目的，对于这样的包，我们难以对它有太多苛求，只有在"组件"级别上，才有必要认真考虑它们之间依赖的设计影响，所以，JDM的不同之处就在于它更人性化地把管理粒度的重点从包转移到了组件—— 一个可以自由定义大小的概念上，使得您可以将概念划分和设计影响“解耦合”。
3）、它很人性化，您可以自定义各种规则不符合到什么程度才是您不可接受的，哦，这也是很多类似工具做得不够的地方，我不用再被迫一刀切地僵化地使用工具了，我可以很方便地定义不同局部的质量要求，可以方便地定义它们不同的警报级别，还可以定义不同问题输出信息的程度——
