Lectures

We break down a practical layered structure for a Go project: the core domain (entities and rules), the app/usecases scenarios (application operations), and the external details adapters (CLI/HTTP/storage). We learn to read the architecture via imports: dependencies go “from the outside in”, and import in Go locks in a dependency at compile time. Using a mini-app as an example, we show the difference between import path and module path, and how to plug in a storage implementation via the TaskStore interface.

We break down Go’s internal/ mechanism: why “don’t export extra stuff” doesn’t always protect your architecture, which rule the go tool enforces, who can import internal packages and from where, where to place internal (at the layer level or at the module root), and how to get the use of internal package not allowed error exactly where a boundary is actually being violated.

We break down “manual” DI in Go: what a composition root ( composition root) in main is, why dependencies shouldn’t be created inside business logic, how to design small consumer-driven interfaces ( TaskStore), how to pass context.Context down the call chain, how to build an application with the NewApp constructor via Deps, and how an adapter ( memstore) “fits” the contract without importing the app layer.

We break down how to build “human-friendly” errors at an application boundary without turning error text into a contract: the domain returns meaning (for example, ErrNotFound or ValidationError), use-cases add context via fmt.Errorf and %w, and CLI/HTTP translate that into a stable format (exit code, status code, JSON) by recognizing causes via errors.Is and errors.As.

We break down why the Go error "import cycle not allowed" is almost always a symptom of broken architecture, how to think of a project as an import graph, and where to keep the “composition root” ( main). You will learn how to build one-way dependencies between domain, app, and adapters, how to declare interfaces from the consumer side (for example, TaskStore), how to use internal/ carefully, and how not to turn common/utils into the center of the spider web.