How chunhthanhde/cinema-booking works
<explanation>
1. Identify the project type and purpose
- This is a cross‑platform mobile (and web/desktop) client application named Cinema Booking built with Flutter, following Clean Architecture + BLoC.
- Purpose: allow users to search movies, view details, auth via Firebase, book seats and time‑slots, and manage tickets.
2. Analyze the file structure
- Top‑level “android”, “ios”, “linux”, “macos”, “windows”, “web” folders → Flutter multi‑target client.
- lib/ folder organized into layers:
• common: shared widgets, helpers, global BLoCs (authentication, theme)
• core: API provider (Dio/Retrofit), configs, constants, local storage helpers, usecase abstractions
• data: models (JSON DTOs), repository implementations, data sources (remote via Retrofit, mock, local)
• domain: entities, abstract repository interfaces, use case classes
• presentation: UI screens and feature‑specific BLoCs (login, home, movie_detail, booking, tickets, etc.)
- Configuration: service_locator.dart (GetIt DI), router.dart (GoRouter navigation), main.dart kicks off app.
3. Examine README insights
- Contains an ERD (Draw.io) linking User, Booking, Movie, Cinema, ShowTime, Seats, Ticket.
- High‑level Clean Bloc Architecture ASCII diagram provided.
- Tech stack: Firebase Auth/Firestore, Dio/Retrofit REST API, SharedPreferences, Sqflite, BLoC, Equatable, Freezed, JSON Serializable, GoRouter, YouTube Player, Google Maps, etc.
4. How to create the system design diagram
a. Main components
- Client App (Flutter)
• Presentation Layer (Widgets, Screens, BLoCs)
• Domain Layer (UseCases, Entities)
• Data Layer (Repositories, DataSources)
• Core Layer (API client, Configs, DI, Local DB)
- External Services
• REST API Server (movie/catalog, booking endpoints)
• Firebase Auth
• Cloud Firestore
• Local Storage (SharedPreferences, SQLite)
• Third‑party libs (Google Maps, YouTube Player)
b. Relationships & Interactions
- UI Widgets dispatch events → BLoC → invokes Domain UseCase → calls Repository Interface → Data Layer picks Remote or Local DataSource → REST API / Firestore / local DB → returns Entities upstream → BLoC emits new states → UI updates.
- Authentication flows: Presentation → AuthBloc → Firebase Auth DataSource → Auth Repository → domain → persists token in SharedPreferences.
- Booking: BLoC → use case to fetch time slots (mock or remote) → user selects → commit booking via REST API → ticket saved in Cloud Firestore and/or local DB → displayed in Tickets screen.
c. Architectural patterns
- Clean Architecture: strict layer dependency (outer layers depend on inner abstractions)
- BLoC: one BLoC per feature/screen to manage state transitions
- Repository Pattern: abstracts data sources, choose remote vs mock/local
- Service Locator (GetIt): resolves dependencies at startup
- Code Generation: JSON Serializable, Freezed, Retrofit generator for DTOs
d. Key technologies
- Flutter UI (Widgets), BLoC (flutter_bloc, hydrated_bloc), GoRouter
- Networking: Dio + Retrofit
- Auth & DB: Firebase Auth, Cloud Firestore, SharedPreferences, Sqflite
- DI: GetIt
- JSON & immutability: json_serializable, freezed, equatable
5. Guidelines for tailoring the diagram
- Full‑stack client: emphasize layered separation within the client app and highlight only external backends (REST API, Firebase).
- Emphasize feature modules (home, booking, movie_detail, tickets) as clustered sub‑components under Presentation.
- Show the ERD separately or as inset to cover Cinema, Movie, User, Booking, Seat, ShowTime relations.
6. Diagram elements to include
- Shapes/Colors:
• Rectangles for layers (Presentation, Domain, Data, Core) colored distinctively
• Cylinders for databases (SQLite, Firestore)
• Clouds for external services (REST API, Firebase Auth)
• Rounded boxes for feature modules (Login, Home, Booking, Tickets)
- Labels: clear names (e.g., “BookingSeatSlotBloc”, “MovieInfoService”)
- Arrows:
• Downward arrows for “depends on / calls”
• Upward arrows for “data flow response”
- Legend: icon or color key for Flutter layers vs external services vs local storage.
7. Detail level
- Capture each layer’s major sub‑components (e.g., under Data: models, repository_impl, remote_service)
- Group similar features (all booking-related BLoCs under one “Booking” container).
- Don’t overcrowd: collapse low‑level widgets into “UI Widgets” cluster but list critical ones (e.g., GoRouter, ServiceLocator).
By following these steps and conventions, you’ll produce a clear, accurate, and detailed system design diagram that reflects the Cinema Booking app’s Clean Architecture, feature modules, and external integrations.
</explanation>