My first response is it is time to refactor.

I often see this sort of thing more as a result of growth and usefulness rather than actual design. First came Module A which was spiffy and had many a good use. Then came Module B and it did much that was cool as well, not the least of which was to make use of A. The story goes on and potentially includes a little creative refactoring of A to make use of D thus creating the circular dependancies.

There are other reasons this happens, such as trying to modularize a relational database and choosing a bad criterion for the initial code seperation. eg. seperating code by client (I've seen it) becaues it was thought the code would never be useful to other clients. Another reason is seperating code by what it does rather than what it does it for (the basis of OO). eg. are we going to copy a file, ftp it, sftp it, or are we doing a Document->move? If you break our code up based on the functions, we often find them being so closely similar to other functions we end up coupling them.

Regardless of whether this design came about over time and wild growth or whether it was designed that way up front, my guess is, if you take a look at how they are currently designed and currently being used, you will find it not so difficult to refactor them into something that is not so convoluted, and considerablly cleaner.

Code, for all we might prefer it to not be, is alive, not static. It grows and changes, as does the need and uses for it. Often times one drives the other and vice-versa. If it's starting to feel uncomfortable (and causing you to question it's validity in public), start reworking it. Your code will thank you for the attention and respond with pleasant purrs and playful barks...