seal88241712-creator/backend

1. Overall shape

- This is a single Spring Boot backend monolith for a campus second-hand trading platform.

- The application is organized in a classic layered architecture: controller → service → mapper → database, with DTO/VO objects separating API contracts from persistence models.

2. Primary business domains

- The codebase centers on nine functional areas: users, goods, categories, orders, chat, AI chat, evaluations, favorites, and announcements.

- Admin-oriented flows are present alongside student/user flows, especially for user audit, goods audit, and platform management.

3. API layer

- controller/ contains REST endpoints for each domain, such as UserController, GoodsController, OrderController, ChatController, AiChatController, and AdminController.

- Controllers accept DTOs, delegate to services, and return unified response wrappers rather than exposing entities directly.

4. Business logic layer

- service/ defines domain services and service/impl/ contains the implementations.

- This is where workflow rules live: publishing goods, approving audits, creating orders, recording evaluations, managing favorites, and assembling dashboard/statistics views.

5. Persistence boundary

- mapper/ holds MyBatis-Plus mappers for the main entities: User, Goods, Category, Order, ChatRecord, Evaluation, Favorite, Announcement, and AI chat history.

- entity/ models map to relational tables in MySQL, while vo/ models are used to shape responses for lists, details, stats, and dashboards.

6. Data flow and object boundaries

- Request payloads use dto/ types such as login/register, goods publish/query, order create/pay/query, audit actions, and chat messages.

- Responses use vo/ types such as UserVO, GoodsVO, OrderVO, ChatMessageVO, DashboardVO, and statistics VOs, which indicates a deliberate separation between storage schema and API output.

7. Security and identity

- Security is built with Spring Security plus JWT.

- The request path likely flows through JwtAuthenticationFilter, which authenticates incoming requests, with UserDetailsServiceImpl and CustomUserDetails backing user lookup and authorization.

- Roles and status are modeled explicitly in enums like UserRole, UserStatus, and GoodsStatus, supporting role-based access control for student/admin behavior.

8. Real-time communication

- Chat is not purely REST-based; it includes WebSocket support configured through WebSocketConfig, WebSocketHandshakeInterceptor, and ChatWebSocketHandler.

- This implies two parallel chat paths: persistent chat history in MySQL via ChatRecord, and real-time message exchange over WebSocket/STOMP.

9. External services and infrastructure

- Redis is configured as a secondary data store/cache, probably for session/token-related data, verification, or short-lived platform state.

- DashScopeConfig suggests integration with an external AI service for AiChatController/AiChatService, likely for AI conversation or recommendation features.

- File uploads are handled separately and stored under the local uploads/ directory, with image upload support exposed via FileUploadController.

10. Cross-cutting framework support

- common/ provides the standard API envelope (Result, PageResult) and centralized error handling via BusinessException and GlobalExceptionHandler.

- config/ contains CORS, Redis, WebSocket, MyBatis-Plus, file upload, and Knife4j/Swagger documentation setup.

- This indicates the backend is designed to be consumed by a separate frontend application and documented through generated API docs.

11. Domain-specific workflows

- Goods lifecycle: publish → audit/approval → browse/search/filter → favorite/chat/order.

- Order lifecycle: create → pay/mock payment → status tracking → evaluation.

- User lifecycle: register/login → JWT-authenticated access → audit/approval for role/status changes.

- Announcement and statistics flows support administrative oversight and platform-wide messaging.

12. Operational and schema concerns

- The repository includes Flyway-style SQL migrations under src/main/resources/db/migration, showing that schema evolution is part of the runtime model.

- Logging is configured via logback-spring.xml, and the build uses Maven with Spring Boot packaging.

- The presence of target/ and generated artifacts indicates a standard Java deployment model: build a runnable JAR, then run it with environment-specific YAML profiles.

13. What to show in an architecture diagram

- Draw one backend service boundary containing API controllers, service layer, persistence layer, security, and WebSocket handling.

- Show MySQL as the primary system of record, Redis as the auxiliary cache/state store, local file storage for uploads, and an external AI service connected to the AI chat module.

- Highlight the request entry points: REST endpoints, JWT-filtered HTTP traffic, and WebSocket connections for chat.