The Dependency Rule: One Import Statement Will Tell You If Your Go Architecture Is Broken

Open your domain package. Read the imports. package domain import ( "context" "fmt" ) Clean. This domain depends on nothing but standard library utilities. Now look at this: package domain import ( "context" "database/sql" "fmt" ) One extra line. database/sql . Your domain now depends on infrastructure. The architecture is broken. The Rule Inner layers must never import outer layers. The domain defines interfaces. The adapters implement them. The domain never knows which adapter is on the other side. That's the entire rule. Adapter ──imports──► Domain ✅ Correct Domain ──imports──► Adapter ❌ Broken What "Depends On" Means in Go In Go, dependency is an import . Nothing else. No annotation-based DI. No classpath scanning. If package A imports package B, A depends on B. Want to know which direction your dependencies point? Open the file. Read the imports. The compiler is your architecture linter. How Violations Sneak In Even experienced developers break the rule accidentally: JSON struct t