liveBook · Manning

Circular dependency

As explained in Go in Action, Second Edition

A circular dependency is a dependency cycle in which packages or modules depend on one another directly or through an intermediate chain.

A circular dependency is a package dependency cycle: package A imports package B while B directly or indirectly imports A. Go rejects the arrangement at compile time, encouraging clear dependency direction and separation of concerns. section 11.1.1

Use package organization to avoid dependency cycles:

  • Separate concerns so dependencies remain understandable and maintainable. section 11.1.1
  • Place shared libraries separately from executables, with cmd commonly containing distinct main packages. section 11.1.1
  • Keep implementation details in internal packages when they should not be imported externally. section 11.1.1
Figure 11.2 Complete directory structure for go-news with domain, storage, API, and worker modules

Browse a complete project layout showing domain, storage, API, and worker modules arranged across packages. section 11.1.1

How Go in Action, Second Edition covers it

How deep it goes
Defines direct and indirect cycles and compiler rejection, but gives no code-level refactoring procedure.
Examples
Uses package A and B dependency cycles plus a directory structure containing domain, storage, API, and worker modules.
What you can do after
Diagnose compiler-rejected package cycles and organize executables, shared libraries, and internal implementation packages.
How it connects
Connects packages with imports, dependency direction, separation of concerns, and project organization.

Also explained in

Compare how 5 books explain circular dependency →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Go in Action, Second Edition. The section links point to the parts of the book it draws on.