This project has moved. For the latest updates, please go here.

Suggestion to ease dependency description

Nov 26, 2015 at 10:22 AM
Hi,

Thank you very much for this fantastic dependency analyzer. I use it intensively in NCase project to enforce dependency rules. After a few months usage, I notice a weakness in the expressiveness of the NsDepCop description file.

In a layer application, the dependency rules are quite simple to describe:
  • On one hand, you have the layer dependencies, typically:
    ui contracts <- ui implementation -> business contracts <- business implementation
  • On the other hand, you have the module dependencies, typically:
    module A -> module B -> module C
This is the way most people conceptualizes the dependencies in a layered architecture.

So, it would be fantastic to be able to formulate the dependency exactly that way. It would require an additional extraction step, where the layer and module information would be extracted from metadata like namespace and attributes.

Currently, you have to repeat every (module, layer) to (module, layer) dependency, resulting in a very verbose and confusing dependency description file.

The alternative project ildasmdc, which is not maintained anymore, offered the possibility to declare such dependency rules: you could use ant-like wildcards anywhere in the namespace description.
Coordinator
Nov 27, 2015 at 9:14 AM
Hi Jerome,

Thanks for the feedback! I'm happy that you found NsDepCop useful.

I'm not sure I fully understand your suggestion.
Can you give an example? Eg. how would you modify the dependency rule description in this file to fit your needs better:
https://github.com/jeromerg/NCase/blob/master/src/NCase.Core/config.nsdepcop

Please note, that I have these concerns when it comes to modifying the rule descriptions:
  1. "Make the right thing easy and the wrong thing hard."
  2. Rules should be explicit.
  3. Rules should use only well defined concepts.
  4. Rules should be backward compatible.
So lets make sure that allowing more freedom in wildcard usage don't hurt concerns '1.' and '2.'
And we have to be careful with concepts like module and layer because thay can mean different things for different people and hurt concern '3.' (Eg. the term "module" means a unit of physical packaging in CLR.)

Btw, I'm planning to create a graphical visualizer/editor for NsDepCop.
Currently I'm working on diagramming tool: https://github.com/realvizu/softvis
But it's still a long way to go until I can use it in NsDepCop for namespace dependency visualization and rule editing.

In the meantime, I'm planning to create a minor release of NsDepCop in Jan/Feb 2016, so if we can came up with some solid enhancements then I can implement them in that timeframe.