• each and every package belongs to a set of slices, with a slice being either a domain module containing code dealing with a certain part of the domain (like, ‘shopping cart’, ‘fulfillment’, ‘customer’) or a technical part of the application (‘presentation’, ‘persistance’, ‘domain’)
• all dependencies between packages and slices are free of cycles

One problem with this set of rules is: Since dependencies aren’t readily visible in the code it is hard to maintain these rules. And once they are broken it is even harder to fix them.

In one project this lead to developers packing lots of stuff in a single package, because they didn’t know where to put new stuff without creating circles. Obviously that was not what we intended with the rules. But what do you do when faced with a package containing 170 classes and the task to break it (as a first step) in a set of smaller packages void of dependency cycles?

There are tools that tell you when you have dependency cycles. Most of the time they show you the problem as a dependency structure matrix. Unfortunately it is really hard to identify a bunch of classes that you can pull out of a package in order to fix a dependency cycle. They tell you even less about which group of classes you can pull out of a package without creating new dependency cycles.

In order to fix this I created Degraph.

Degraph analyses the dependencies of a bunch of class or jar files and creates a graph representation of it. In this graph it also groups classes into packages and if you want into slices. The result is written to disc as a graphml file. This file can then be opened with yed, a free graph editor with strong layout capabilities.

The result looks like the following image (click for a larger version).

You can see packages as boxes containing classes. If the classes contain inner classes those are contained in the boxes representing the outer classes. What is not visible in the image is that you can open and collapse the boxes representing packages or classes with inner classes. This enables you to show that part of the dependencies that you actually care about.

If this sounds interesting to you give it a try. You can download the current distribution and install it by unzipping it (you’ll need a a properly installed JRE). You can find more instructions on how to use and configure Degraph in its wiki

Degraph is obviously at a very early stage of development, but it is still useful (and fun) if you want to have a look at the structure of your class dependencies. While it shows you the dependency and allows you to identify cycles visually, so far it doesn’t identify such cycles on its own. I’m currently working on adding that ability.

Probably next is the option to integrate Degraph in JUnit (or other) automated tests.

Beyond that I have tons of ideas (definition and test of allowed/disallowed dependencies, creation of dot files, interactive specialized ui, identification of dependencies to break, integration of spring file analysis ..) but this will obviously take some time. In the mean time: If you find a bug, have a problem or an idea for improvement, leave a comment or open an issue.