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 developer is building a blog platform backend in Go. The API needs to manage blog posts (create, read, update, delete) and comments on posts. Posts have an author, title, body, tags, and publication status (draft/published). Comments belong to a post and have an author name and body.
The developer previously had everything in one big main.go and wants to restructure it properly from scratch.
Produce a complete project structure with:
go.mod with module pathcmd/api/main.go -- entry point with dependency wiring (repository -> service -> handler), HTTP server with read/write timeouts from config, graceful shutdowninternal/config/config.go -- Config loading PORT, DATABASE_URL, ALLOWED_ORIGINS from environment with defaultsinternal/domain/models.go -- Post (ID, AuthorID, Title, Body, Tags, Status, CreatedAt, UpdatedAt), PostStatus (draft/published), Comment (ID, PostID, AuthorName, Body, CreatedAt), CreatePostRequest, UpdatePostRequest, CreateCommentRequestinternal/domain/errors.go -- AppError, NotFoundError, ValidationErrorinternal/handler/ -- Handler struct, route registration with middleware (logging, recovery, CORS), POST/GET/PUT/DELETE for posts, POST/GET for comments on a post, writeJSON and writeError helpersinternal/service/posts.go -- PostService with business logic (validate required fields, check status transitions), defines PostRepository interfaceinternal/service/comments.go -- CommentService, defines CommentRepository interfaceinternal/repository/posts.go -- SQL-based PostRepointernal/repository/comments.go -- SQL-based CommentRepoMakefile with build, run, test, lint, fmt, tidy targets.gitignore for Go projectsinternal/service/posts_test.go with table-driven tests for post creation validation and status transitions