This review warns you about future circular dependencies.

Consider the example below:

Package1 depends on Package2, but Package2 has an implicit dependency on Package1 because it has an attribute using a data type from Package1.

If a dependency was added from Package2 to Package1 then there would be a circular dependency.

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.

If the packages do not represent file based concepts then you may wish to ignore these problems, but even if this is the case you may want to think about resolving the issue as it often suggests conceptual or analytical problems within the model.

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.

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 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.

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…