nxvxrloseee/coursework

1. This repository is a multi-client repair-service platform with one shared backend and two user-facing clients. The backend is the system of record; the React web app is for master/admin workflows, and the Flutter app is for customers.

2. The backend lives in RD/ and is a Spring Boot 3.5 application on JDK 17. It uses PostgreSQL with JPA/Hibernate as the main persistence layer, and ddl-auto=update indicates the schema is managed from entities rather than migrations. The backend is containerized and meant to run with its supporting services through docker-compose.yml.

3. The backend’s core domain is ticket-centric. The main entities model users, roles, ticket categories, tickets, ticket services, status history, ticket messages, media attachments, services/price items, and notifications. That gives the architecture a clear transactional boundary around “repair ticket lifecycle” plus supporting catalog and communication data.

4. The request boundary is REST controllers in controller/, backed by service-layer orchestration in service/ and repository access in repository/. The important services are TicketManagementService, ChatService, DashboardService, NotificationService, UserService, AuthService, FileService, and PriceListService, which map closely to the business areas exposed by the clients.

5. Authentication and authorization are centralized in security/ with JWT-based auth (JwtProvider, JwtFilter) and SecurityConfig. The README notes refresh handling via httpOnly cookie and bcrypt password hashing, so the auth boundary is stateful at the browser/app edge but stateless in the main request pipeline.

6. Real-time communication is a separate subsystem. WebSocketConfig and the chat DTOs/controllers indicate STOMP-based WebSocket messaging for ticket chat and live updates. This sits alongside REST, not inside it, so chat is likely a mixed model: REST for history/state, WS for live message delivery.

7. Async/infrastructure integrations are first-class in the backend config: RabbitConfig, RedisConfig, and MinioConfig. RabbitMQ and Redis support cross-cutting concerns such as notifications and transient state/caching, while MinIO handles file/object storage for ticket media and uploaded artifacts. FileController and FileService are the boundary for that object-storage flow.

8. NotificationController, NotificationService, and the notification DTOs/entities form a dedicated notification pipeline. The mobile client also has a push_service, so the system likely combines backend-generated notification events with device push delivery on the customer side.

9. The dashboard subsystem is isolated around DashboardController/DashboardService and returns analytics DTOs such as revenue points and summary responses. This implies a reporting/read-optimized path separate from the transactional ticket CRUD path, which is important for diagramming read vs write responsibilities.

10. DataSeeder indicates the backend bootstraps initial reference data, likely roles/categories/services, so some parts of the domain are initialized automatically at startup. GlobalExceptionHandler and ApiException define the error boundary and consistent API failure responses.

11. rd-master/ is the operator UI built with React, Vite, and TypeScript. It consumes the backend through dedicated API modules (src/api/*), uses a client wrapper, maintains auth and notification state in stores, and includes a WebSocket hook for live ticket/chat updates. Its pages map directly to backend domains: dashboard, tickets, history, notifications, services, profile, login, and ticket detail.

12. rd-customer/ is the customer-facing Flutter app targeting Android/iOS and other Flutter platforms. It has its own API layer and screens for login/register, ticket creation, ticket history/details, notifications, profile, and guest access. This client is narrower than the web app and focuses on self-service ticket submission and chat follow-up.

13. Operationally, the system is packaged for local/container deployment. RD/docker-compose.yml brings up the backend plus PostgreSQL, Redis, RabbitMQ, MinIO, and the web frontend, while backup.sh supports PostgreSQL dump/restore workflows. That makes the deployment topology a small service stack centered on the Spring backend rather than a distributed microservice mesh.