Go Architecture Patterns

Build Workflow

1. Let the existing repo architecture lead. Preserve established package naming, dependency injection, and test style unless there is a concrete problem.
2. Design boundaries around behavior and data ownership, not pattern names.
3. Accept interfaces at the consumer boundary. Return concrete types unless hiding implementation is part of the API.
4. Keep interfaces small. Prefer io.Reader-style capability interfaces over broad service interfaces.
5. Keep domain/service packages independent of transport, database, CLI, logging, and framework details.
6. Keep concurrency out of APIs when possible. Expose synchronous functions; let callers decide whether to run them in goroutines.
7. Introduce repositories, ports/adapters, or functional options only when they remove real coupling or constructor complexity.
8. Document tradeoffs in plans: dependency direction, concrete vs interface boundaries, test fakes, and simpler alternatives.

Audit Workflow