How guinea-cat/database-pj works
1. This is a three-part airline ticketing system: a MySQL database layer, a Spring Boot backend on port 8080, and a React + TypeScript frontend on port 5173. The backend is the main business engine; the frontend is a thin client that calls backend APIs.
2. The database folder is the source of truth for the domain model. schema.sql defines the airline-ticket schema, and seed_data.sql loads demo data. The README says the project is intentionally limited to 9 core tables, matching the ER design used in the course project.
3. Backend entry point is AirticketApplication.java. The backend is organized in a classic layered structure: controllers handle HTTP, services implement business rules, repositories access data, entities represent tables, and DTOs isolate request/response payloads.
4. The HTTP boundary is split by business capability rather than by generic CRUD. Main controllers are AuthController, AdminController, TicketController, PassengerFlightController, MealController, and MemberController, which suggests separate flows for login, administration, ticket operations, passenger-facing flight browsing, meal-related actions, and member account actions.
5. Business logic is concentrated in services: AuthService, AdminService, TicketService, FlightSearchService, and ExpiredOrderService. These services likely orchestrate validation, state transitions, pricing/discount logic, order creation, payment/refund/change flows, and admin maintenance operations.
6. Persistence is centered on domain repositories for User, City, Airport, Aircraft, Flight, FlightSegment, MealOption, MealReservation, and TicketSale. This shows the core data model spans reference data, flight structure, selling/orders, and optional meal reservations.
7. The domain layer uses enums to control business state: CabinClass, FlightStatus, MemberLevel, TicketStatus, and UserType. These enums are important architectural boundaries because they encode workflow and permissions, not just labels.
8. Several cross-cutting components shape runtime behavior. GlobalExceptionHandler and BusinessException provide centralized error handling; ApiResponse and PageResult standardize response payloads; CorsConfig enables frontend-to-backend access; SecurityUtil likely handles current-user context or auth helpers.
9. Order lifecycle is time-sensitive. TicketExpireScheduler and ExpiredOrderService indicate the backend runs a scheduled job to expire unpaid orders automatically, so ticket state is not purely request-driven.
10. Ticket and member flows appear to be the most stateful part of the system. The DTOs include create/pay/refund/change requests and responses such as TicketResponse and AuthResponse, which suggests the backend exposes explicit workflow endpoints rather than only CRUD on tickets.
11. The frontend is a Vite-based React app with TypeScript. src/api/client.ts and src/api/airticket.ts are the integration boundary to the backend, while types.ts and lib/display.ts show the UI is driven by typed backend data and display helpers.
12. Testing is present on both backend and frontend sides. Backend tests cover services and DTO behavior, while frontend tests cover the API client and display utilities, indicating the architecture relies on service-level correctness and frontend contract checks rather than heavy end-to-end automation.
13. Operationally, the system depends on MySQL plus standard Java/Node toolchains. The backend is packaged with Maven, and the frontend is developed with npm/Vite; the database scripts and documentation in docs/ are part of the system design, not just auxiliary notes.
14. For an architecture diagram, the main data flow is: browser UI -> frontend API client -> backend controllers -> service layer -> repositories -> MySQL, with schedulers acting on the database in the background and exception/response wrappers shaping the API boundary.
Main entry points: service Services · controller Controllers · schema.sql MySQL DB · client.ts API Client
Components 18
Frontend
React + TypeScript client and API integration layer
- React UI · Vite-based React and TypeScript client
frontend/src/App.tsx - API Client · Frontend integration boundary to backend endpoints
frontend/src/api/client.ts - Display Utils · Formatting and display helpers for backend-driven data
frontend/src/lib/display.ts
Backend
Spring Boot business engine and layered API
- App Entry · Backend application bootstrap
backend/src/main/java/com/example/airticket/AirticketApplication.java - Controllers · Capability-based REST endpoints for auth, admin, tickets, flights, meals, and members
backend/src/main/java/com/example/airticket/controller - Services · Business rules and orchestration for auth, admin, ticketing, flight search, and expiry
backend/src/main/java/com/example/airticket/service - Repositories · Persistence interfaces for core airline domain entities
backend/src/main/java/com/example/airticket/repository - Entities · JPA entities mirroring airline tables and relationships
backend/src/main/java/com/example/airticket/entity - DTOs · Request and response payloads isolating API inputs and outputs
backend/src/main/java/com/example/airticket/dto - Enums · Cabin, flight, member, ticket, and user type state boundaries
backend/src/main/java/com/example/airticket/enums - Errors · Business exception and centralized API error mapping
backend/src/main/java/com/example/airticket/exception - Responses · Standard API response and pagination wrappers
backend/src/main/java/com/example/airticket/common - Security Util · Current-user and security context helper functions
backend/src/main/java/com/example/airticket/util/SecurityUtil.java - CORS Config · Cross-origin access from frontend to backend APIs
backend/src/main/java/com/example/airticket/config/CorsConfig.java
Data
MySQL schema and seed data as the domain source of truth
Runtime
Cross-cutting runtime support and scheduled jobs
- Expiry Job · Background job that expires unpaid orders
backend/src/main/java/com/example/airticket/scheduler/TicketExpireScheduler.java
Connections 20
- App Entry → Controllers: starts · Bootstraps the HTTP API
- Controllers → Services: delegates · Routes capability-specific requests into business logic
- Services → Repositories: queries · Reads and writes persisted domain state
- Repositories → Entities: maps · Repository layer persists entity models
- Entities → MySQL DB: stores · Entity state is materialized in MySQL
- Schema → MySQL DB: defines · Schema establishes the core domain tables
- Seed Data → MySQL DB: loads · Demo data populates the database
- Controllers → DTOs: accepts/returns · HTTP endpoints use request and response DTOs
- Services → DTOs: uses · Service methods assemble and validate payloads
- Services → Enums: applies · Workflow and permission states constrain behavior
- Services → Errors: throws · Business failures are centralized as exceptions
- Errors → Responses: formats · Error handling produces standardized API responses
- Controllers → Responses: wraps · Responses are normalized for the frontend
- Services → Security Util: checks · Business logic can inspect current-user context
- Expiry Job → Services: invokes · Background expiry workflow reuses business logic
- Expiry Job → MySQL DB: updates · Expired orders are reconciled against persisted state
- React UI → API Client: calls · Browser UI talks through the frontend API client
- API Client → Controllers: requests · Frontend sends HTTP requests to backend endpoints
- React UI → Display Utils: renders · UI formatting uses shared display helpers
- API Client → CORS Config: crosses · Frontend access depends on CORS configuration