Dependency management controls which components know about and rely on others. Its goal is not to eliminate collaboration: a service can delegate work to repositories and entities. The goal is to keep that collaboration from turning ordinary changes into unpredictable, cascading maintenance work. section 4.0 section 1.2
Treat every dependency as a possible path for change propagation. When Basket depends on DiscountRules, Product, and Customer, changes in those components—and even in transitive dependencies such as DiscountRepository—can force Basket to change. Prefer fewer dependencies, less knowledge between classes, and dependencies on components that are relatively stable. section 1.2.3
Keep dependencies manageable by making exposure deliberate:
- Avoid depending on another component’s implementation details; internal refactorings should not require widespread client changes. section 4.2
- Expose only the minimum information a client needs, and conceal details likely to change. section 4.2
- Question whether a class needs each dependency and whether frequently changing code can sit behind a more stable abstraction. section 4.2
- Accept useful delegation while resisting dependencies added without a clear responsibility or boundary. section 4.0
Change propagation
If Product changes often, Basket remains at risk whenever it directly relies on Product. The risk grows when Basket also relies on DiscountRules and Customer, because each relationship can carry changes or defects into Basket. Reducing unnecessary knowledge limits the surface exposed to those changes. section 1.2.3 section 4.0
Dependency management works with abstraction design. Coupling to a stable abstraction is less troublesome because it is less likely to change; coupling to exposed details is fragile. This is ongoing design work, not a one-time cleanup: complexity naturally grows, so preserve simple relationships through regular attention and pragmatic refactoring. section 5.1.6 section 1.7 section 8.8
Use the dependency diagram to trace direct and transitive paths through which a change can reach a client class. section 1.2.3
