How doocheol/marimo works
<explanation>
1. Project type and purpose
- This is a full‑stack vehicle maintenance and management system.
- Frontend: a multi‑platform Flutter app that connects via Bluetooth to an OBD2 scanner, runs on‑device AI for tire analysis and voice input, and displays maps, payment, insurance and chat features.
- Backend: a Java Spring Boot REST API with layered architecture, persisting data in MySQL, caching in Redis, securing endpoints with JWT, and integrating with external services (financial network, gas‑price API, ChatGPT API).
2. Key file‑structure signals
- Top‑level directories “marimo_client” (Flutter) and “marimo-server” (Spring Boot).
- Flutter uses “lib/screens”, “lib/services”, “lib/providers” following MVVM/provider pattern.
- Server follows MVC/layered pattern: controllers, services, repositories under “src/main/java/com/ssafy/marimo”.
- Configurations for security, JPA, Redis, external WebClient.
- Build and deployment: Dockerfile, AWS Jenkins, Nginx, Gradle wrapper, Flutter build artifacts.
3. Creating the system‑design diagram
a. Main components (use distinct boxes/colors):
• Flutter Client
– UI layer (screens/widgets)
– Business logic (providers)
– Services layer (HTTP client, Bluetooth serial, TFLite interpreter, voice STT, local chat model)
– On‑device AI models (tire‑wear TFLite, Gemma 3 chat)
• Spring Boot API Server
– API Gateway / Controllers (Auth, Car, Card, Insurance, Navigation, Payment, External)
– Service layer (business rules, external integration logic)
– Repository layer (JPA repositories, QueryDSL)
– Cross‑cutting concerns (security filters, aspects, exception handlers)
• Persistence
– MySQL (relational data: member, car, payment, insurance, navigation, etc.)
– Redis (cache for user’s monthly spend, card benefits)
• External services
– OBD2 hardware (via Bluetooth on client)
– SSAFY financial network API for card data
– Opinet gas‑price API
– ChatGPT API (for backend code‑analysis prompting)
– AWS RDS, AWS EC2, Nginx, Jenkins, Docker registry
b. Relationships and data flow (directional arrows):
1. Client UI → Business logic → HTTP requests → Spring Boot Controllers
2. Controllers ↔ Services ↔ Repositories → MySQL / Redis
3. Services ↔ external REST APIs (financial, gas, chat)
4. Client Bluetooth module ↔ OBD2 hardware
5. Client TFLite interpreter ↔ on‑device AI model files
6. CI/CD: Jenkins triggers Docker build → deploys on AWS EC2 behind Nginx → connects to RDS and Redis
c. Architectural patterns and principles
- Frontend: MVVM (Widgets ↔ Providers ↔ Services), separation of concerns
- Backend: MVC / layered architecture, single responsibility, dependency injection, aspect‑oriented logging
- Caching pattern: cache‑aside with Redis to reduce external API calls and solve N+1
- Secure token‑based authentication: JWT filter chain
- Circuit breaker / retry (if shown) for external APIs (WebClient)
d. Technologies and frameworks
- Flutter, Provider, flutter_bluetooth_serial, TFLite, STT, on‑device Gemma 3
- Spring Boot 3.4, Spring Security, Spring Data JPA, QueryDSL, WebClient
- MySQL 8, Redis 7
- Docker, Jenkins, AWS EC2/RDS, Nginx
4. Diagram‑tailoring guidelines (full‑stack emphasis)
- Draw two main vertical lanes or layers: Frontend (left) and Backend (center).
- Show Persistence (MySQL, Redis) below backend.
- Place External Services (right) for financial API, gas API, ChatGPT.
- Show OBD2 hardware and on‑device AI as sub‑components of the client.
- Illustrate CI/CD and deployment as a separate infrastructure layer at the bottom.
5. Diagram elements to include
- Clear labels on every box (e.g., “CarService”, “RedisCacheConfig”, “BluetoothHelper”)
- Directional arrows with annotation (e.g., “REST/HTTPS”, “Bluetooth RFCOMM”, “TFLite inference”)
- Color coding or shapes:
• Blue boxes for client components
• Green boxes for backend modules
• Orange cylinders for databases
• Gray clouds for external services
• Purple boxes for AI/ML models
6. Detail guidance
- Represent each backend module (auth, car, payment, etc.) as sub‑boxes inside the API server box.
- Inside the client box, separate UI, Provider, Service, and AI model areas.
- Show caching: arrow from CardService to Redis, fallback to external financial API.
- Depict security: arrow from Flutter passing JWT to Spring Security filter.
- Capture deployment: Docker container icon for API server, AWS icon for EC2, RDS icon for MySQL.
Use this framework to build a complete architecture diagram that accurately reflects Marimo’s multi‑layer, multi‑component design, ensuring you capture all essential interactions, technologies, and boundaries.
</explanation>