As a general rule of thumb you should depend in the direction of stability (The Stable Dependencies Principle (SDP)). A package should only depend upon packages that are more stable than it is. If something is changing a lot it we should not depend on it. If it isn’t then we can comfortably reference it as a versioned package/assembly.
“But I want to add something to the GeneralFunctions/Domain/Utilities project”
Why? If you are the only one using it then there is no reason for it to be there.
“But someone else may want to use it in the future”
The possibility that someone may is not a good enough reason to put it there. Follow the principle of You Aren’t Gonna Need It (YAGNI).Â
“But what if I need to change something that already exists?”
“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification” – The Open Closed Principle
In this context, a package is said to be more stable if it has less dependencies on other packages.
If a package depends on lots of other packages, then a change to any none of these packages may force us to recompile, retest and redeploy that package. Packages that depend more on other packages are said to be more “instable”.
So we should favour depending on packages that have fewer dependencies on other packages (are less instable).
That’s one way to measure the stability of a package and a very good one because it can be measured through metrics such as Afferent and Eferrent coupling. However, in my humble understanding there are other ways. You could also identify unstable packages by checking the change logs in your source control repository or by speaking to colleagues.
I have interpreted it thus to illustrate a particular issue we are facing where we have a some “mother” (e.g “Common”, “Domain”) packages which all our products are using and have become a dumping ground for all and sundry. What is worse is that none of these mother packages are being versioned and used as compiled assemblies, but are being included as projects within the solutions so are being considered part of the source code for each product.
I hope, in your eyes, this is a satisfactory interpretation of the SDP.
SDP has a very well-defined meaning in so much as “stability” and “instability” have well-defined meanings in the context of package dependencies.
Instability = efferent couplings / (efferent + afferent couplings)
Stability = 1 – instability
Any other interpretation wouldn’t be the SDP 🙂
Among other places I referred to the c2wiki which suggests this is not always the case:
http://c2.com/cgi/wiki?StableDependenciesPrinciple
Not a reliable source I suppose…