In an earlier post I already mentioned the importance of looking at the dependencies within your codebase. I used a beautifull small tool from Jamie Penney that could generate a file containing graph-information, that in turn could be used with the open source version of GraphViz to finally get a drawing of the project references.
Of course, that way of investigating your dependencies is quite cumbersome. If you need to look at dependencies for professional software, it’s time to use a professional tool like NDepend.
With NDepend you can add project assemblies by simply dragging them into the tool. For example, here is a picture that shows when I added a subset of projects from a very big framework application that we happen to use at work.
At the left are the compiled assemblies (the *.dll files) that I dragged into the NDepend project, on the right NDepend has automatically added all the assemblies where mine are depend upon. This includes .NET assemblies; do not worry about that though, as you can discard these automaticly added assemblies later if you do not want to include them in your investigation.
Pressing (F5) or
Now viewing a graph of dependencies does not, at first, show what I want:
By default, NDepend shows -all- the assemblies that are part of the NDepend project. So, that includes the automatic added related assemblies that were added when we dragged our own assemblies into NDepend. However, going to the graph matrix view, we can change this behaviour of NDepend by selecting only the assemblies we would really like to see. Holding the shift key we select our own assemblies again:
Now press a small button at the top of the screen to export the matrix dependencies to graph.
Now after we pressed the ‘select graph‘ button you eventually will end up with something like this:
Above is the result of right-clicking NHibernate and selecting ‘keep only nodes that use me’, which shows what assemblies are referring to NHibernate. Which turns out more then I thought, oops.
This way, you can actually find out what assemblies are relying on your infrastructure, and thus what domain assemblies still have to change so that those are infrastructure-independent.
Unfortunately, in the above graph there are some domain assemblies (maybe indirectly) dependent on NHibernate. The domain (like airtrade.business) should not depend on the infrastructure as that would give the domain a reason to change if the infrastructure changes as explained by Udi Dahan in his Fetching Strategy Post.
Not what we want. The domain should be able to change totally independent of the infrastructure. Getting out of this mess will mean trying to remove the dependency from the business domain assembly on NHibernate. Before that is possible, we might need to change a LOT of code… For example, as locations is also indirectly coupled with NHibernate, we might need to change code in that assembly as well before we can remove the link from business to NHibernate. Ouch! Luckily NDepend easily uses your PDB (program debug files) to enable clicking directly from NDepend into your source code! That sounds promising, doesn’t it?
Find out more on www.ndepend.com