apollo-level2-web-dev/gotickets

1. Overall shape

GoTickets is a layered Go REST API for ticket booking. The repository is organized around three business domains — user, event, and booking — with shared infrastructure for config, HTTP server setup, authentication, middleware, and uniform error responses.

2. Application entrypoint and startup flow

cmd/main.go is the bootstrapping point. Startup likely follows this order: load environment variables, build configuration, open the PostgreSQL connection, initialize the Echo server, register routes, and start listening on the configured port.

3. Configuration and persistence boundary

internal/config owns environment-driven setup. config.go reads values like PORT and JWT_SECRET, while db.go creates the GORM/PostgreSQL connection from the DSN. The database layer is not a separate service; it is shared infrastructure used by all domain repositories.

4. HTTP server and routing boundary

internal/server/http.go is the central composition point for the web layer. It creates the Echo instance, attaches middleware, registers feature routes, and exposes a health endpoint. This package is the boundary between external HTTP traffic and the domain layer.

5. Domain-oriented feature modules

Each business area lives under internal/domain/<feature>:

- user for registration, login, and profile lookup

- event for event management

- booking for reserving tickets and listing a user’s bookings

Each domain contains its own handler, service, repository, entity, route registration, and DTOs, so the feature boundaries are explicit and self-contained.

6. Request/response shaping with DTOs

Each domain has dto/request.go and dto/response.go packages. These are the API contract layer: handlers use request DTOs for validation/parsing and response DTOs to control what leaves the service boundary. This keeps HTTP payloads separate from database entities.

7. Handler → service → repository flow

The core runtime path is consistent across features:

- routes map URLs to handlers

- handlers parse/validate input and build responses

- services hold business rules

- repositories execute GORM queries

This separation is the main architectural pattern in the repo and is the most important thing to show in a diagram.

8. Authentication subsystem

internal/auth/jwt.go implements token creation/validation. internal/domain/user is the identity source for login and current-user lookup. The auth boundary is enforced at the HTTP layer, not inside repositories.

9. Protected routes and middleware

internal/middlewares/auth.go guards protected endpoints such as bookings and GET /auth/me. The middleware validates the Bearer token, extracts user context, and makes that identity available to downstream handlers/services. This is the key cross-cutting concern in the system.

10. Business rules by domain

The booking service is where ticket availability and reservation logic belongs; it depends on both event and user data. Event handlers/services manage event CRUD-style operations. User handlers/services manage registration, login, and profile access. The main business coupling is booking’s dependency on event inventory and authenticated user identity.

11. Database model and schema management

Domain entities map to GORM models, and the README indicates tables are created via AutoMigrate on startup. There is no dedicated migrations subsystem in the tree, so schema creation is embedded in application initialization rather than handled externally.

12. Shared HTTP error formatting

internal/httpresponse/error.go suggests a common error-response shape used across handlers. This is a small but important shared contract for consistent API responses and easier client consumption.

13. Operational/tooling concerns

.air.toml enables live reload during development, and .env.example documents runtime configuration. The repo is a Go module with Echo, GORM, PostgreSQL, JWT, validation, and godotenv as the practical runtime stack; these materially define how the app starts, validates input, and persists data.

14. Diagram takeaway

A good architecture diagram for this repo should show:

external HTTP clients → Echo server → middleware/auth gate → domain handlers → services → repositories → PostgreSQL,

with JWT auth as a supporting subsystem and config/database initialization as the startup foundation. The main internal boundaries are by domain feature rather than by technical layer alone.