{} The Go Reference

Designing systems

Software Architecture in Go

Code that compiles is easy; code that stays changeable for years is architecture. This track covers the ideas that keep a Go codebase coherent as it grows — Domain-Driven Design and bounded contexts, aggregates and repositories, hexagonal/clean architecture, an idiomatic project layout, and knowing when a modular monolith should become microservices.

Your architecture progress

Mark a topic “learned” on its page and watch the bars fill.

Skill map

Learned nodes light up — the glowing one is your next step. Click any node to jump in.

Principles & Modeling

How to shape a system — modeling the domain with DDD, aggregates and repositories, and keeping business logic clean with ports & adapters.

Structure & Boundaries

Where the lines go — an idiomatic Go project layout, and the modular-monolith-vs-microservices decision and how to evolve between them.

🐹 Architecture is about change, not diagrams

The point of good architecture isn't a pretty diagram — it's that the next change is cheap and safe. Go's small interfaces, explicit dependencies, and lack of magic make clean boundaries natural: depend on interfaces, keep the domain free of I/O, and let the compiler enforce the lines. Start simple (a well-structured monolith) and add structure only when a real force — a team, a scaling need — demands it.