Go project structure -- cmd/internal layout, handler/service/repository layers, Makefile, config from environment, domain error types, test placement, dependency injection
90
84%
Does it follow best practices?
Impact
100%
1.02xAverage score across 5 eval scenarios
Passed
No known issues
A logistics company needs a REST API to manage warehouse inventory. The API tracks products, stock levels, and inventory movements (receiving stock, shipping out, adjustments). It uses PostgreSQL for storage and needs to be production-ready with proper error handling and configuration.
The team is experienced with Go but has been writing everything in a single main.go file. They want this new service to follow best practices for project organization.
Produce a complete project structure with:
go.mod with module pathcmd/api/main.go -- entry point with dependency wiring, HTTP server setup with timeouts, graceful shutdown with signal handlinginternal/config/config.go -- Config struct with fields for PORT, DATABASE_URL, READ_TIMEOUT, WRITE_TIMEOUT loaded from environment with defaultsinternal/domain/ -- Domain types: Product (ID, SKU, Name, Description, Category), StockLevel (ProductID, Warehouse, Quantity, UpdatedAt), InventoryMovement (ID, ProductID, Type [receive/ship/adjust], Quantity, Reason, CreatedAt), relevant request typesinternal/domain/errors.go -- Error types with AppError base, NotFoundError, ValidationError, ConflictError (for duplicate SKUs)internal/handler/ -- Handler struct with constructor, route registration (chi or mux), endpoints for products CRUD and stock operations, centralized writeJSON/writeError helpers, middleware (logging, recovery)internal/service/ -- ProductService and InventoryService with business logic, define repository interfacesinternal/repository/ -- SQL implementations of repository interfacesMakefile with build, run, test, test-coverage, lint, fmt, tidy, clean targets.gitignore appropriate for Gointernal/service/inventory_test.go with table-driven tests for stock level validation (cannot go negative, etc.)Focus on correct package separation and the dependency flow: handler -> service -> repository.