Breaking these rule can sometimes seem like a fast way to workaround or fix an issue. But most often it leads to unnecessary technical debt and complexity. Afterwards it usually gets difficult to fix it as new things are building on top of a bad dependency architecture and bigger and bigger refactoring needs arise. That's why you want to make rule violations visible. You want to prevent design flaws already before new code is merged to the main branch.

See an example below how we illustrate the case in code review.  Here new dependencies have been added that violated the rules (example simple rule):

To prevent intentional and unintentional breaking of the design with bad dependencies, Softagram lets you define dependency rules for your projects. You can define the severity of each violation types, and give clear text reasoning for the author why he's seen the error in first place. If you are already using Softagram, read more on defining the rules from this help file.

Warning in the code review report if an unwanted dependency is being added.

Softagram dependency rule checks allows also effective refactoring. New interface modules would not allow any more imports with automated checks. Existing refactoring needs can be also seen clearly as they are visualized in the whole code base model browsable with Softagram Desktop.