According to the Stable Dependencies Principle, the dependencyshould be in the direction of the stabilityBut:if you don't know what types of changes are likely, it is best to wait and see what happens as the system evolves. Now:Say I'm designing a blog, I am tempted to think the stability ranking is:Comment - less likely to changePostUser - more likely to change (because it's bigger?)If I let Comment depend on Post, then Comment will change more likely. But also vice-versa, if I let Post depend on Comment, Post will change more likely, correct?This wants to be a general argument, every app has a hierarchy similar to users, a main object and children.Where is my best bet for change? higher level classes or lower level? And why?
Depend in the direction of stability: How do I know what is more stable?
design;dependency management
It's not about what is most likely to change, it's the difficulty of changing it.The document you linked actually explains it quite well:Stable roughly means hard to change, whereas instable means  easy to change.The concept can be better thought of as layers of software, it might be easy to change a UI, but much more difficult to change the API it calls, and even more difficult to change the DB that it is built upon. The DB is the stable part there.For other systems, it might be really difficult to change the UI (e.g. a desktop app rolled out to 10,000 remote users) in which case it becomes the most stable.