Reviewer > Provided PTC reviews > Componentization reviews > Circular dependencies (Reviewer Review)
  
Circular dependencies (Reviewer Review)
Circular dependencies are where a package ultimately has a dependency on itself.
Consequences
The consequences of broken dependencies will depend on what the packages represent.
If the packages represent distinct implementation packages, then dependency problems will compromise the architecture of your solution.
If they are not solved in the model, then the implementation of your solution will need re-architecting or it may not compile.
Strategy
If the packages do not represent file based concepts then you may wish to ignore these problems. However, you may nevertheless wish to think about resolving the issue, as it often suggests conceptual or analytical problems within the model.
Fixing Dependency Problems
Broken and cyclic package dependencies can be symptomatic of a poor architecture and may lead to implementation problems.
If you're using packages as an analytic grouping mechanism then it probably isn't such a problem. If packages represent libraries or assemblies then this can cause problems in reuse.
Example
Let's say there's an inventory system and a sales system.
The sales system has lots of responsibilities, such as invoicing, keeping wish lists, tracking page visits. One responsibility is to tell the inventory system to reduce stock based on a sale.
The inventory system has responsibilities like knowing where items are stored, and it needs to work out its re-order level based on sales and which items are being viewed on the website.
This is a cyclic dependency. We can't have one system without the other.
The simple solution
The simplest solution is to abandon packaging by putting everything in one big package.
This may be a solution, but it probably isn't the best solution. We've abandoned controlling cohesion and coupling.
Analysis
There's a clue that the packages aren't well defined. If the sales system is keeping wish lists and performing analytics it's not just a sales system.
This sort of poor cohesion will inevitably lead to packaging issues.
So another solution might be to break that functionality out into a different package.
…other solutions include subscribing to events…
…and implementing interfaces…