Architektur-Übersicht¶
Gesamtarchitektur¶
CC-Sprint ist eine Desktop-Anwendung basierend auf Tauri 2.0, die eine React-Frontend mit einem Rust-Backend kombiniert. Die Architektur folgt dem Prinzip der klaren Trennung zwischen UI, Business-Logik und Datenhaltung.
Kernkomponenten¶
Frontend (React)¶
Technologie-Stack: - React 18.2 - TypeScript 5.3 - TailwindCSS 3.4 - Vite 5.0 (Build-Tool)
Hauptkomponenten:
| Komponente | Zweck | Datei |
|---|---|---|
| ProjectSelector | Projekt erstellen/öffnen | app/src/components/ProjectSelector.tsx |
| ItemList | Tabellen-Ansicht aller Items | app/src/components/ItemList.tsx |
| ItemDetailView | Detail-Ansicht einzelnes Item | app/src/components/ItemDetailView.tsx |
| DependencyGraph | Visualisierung der Abhängigkeiten | app/src/components/DependencyGraph.tsx |
| ConflictBanner | Konflikt-Auflösung UI | app/src/components/ConflictBanner.tsx |
State Management: - Zustand: Lightweight State Management für globalen App-State - TanStack Query: Server State Management für Tauri Command Caching
Backend (Rust)¶
Technologie-Stack: - Rust 1.76+ (Edition 2021) - Tauri 2.0 - SQLite 3 (via rusqlite 0.31)
Schichten:
1. Commands Layer (src-tauri/src/commands/)¶
API-Schicht zwischen Frontend und Backend. Jeder Command ist eine asynchrone Funktion, die vom Frontend aufgerufen werden kann.
Beispiele:
- project.rs: create_project(), open_project(), get_project_info()
- items.rs: get_items(), update_item(), save_backlog()
- dependencies.rs: add_dependency(), check_cycles()
2. Services Layer (src-tauri/src/services/)¶
Orchestrierung von Business-Logik und Daten-Zugriff.
| Service | Zweck |
|---|---|
backlog_service.rs |
Koordiniert Parser, Renderer und Repository |
file_watcher.rs |
Überwacht Backlog.md auf externe Änderungen |
id_generator.rs |
Generiert eindeutige IDs (F-0001, T-0042, etc.) |
3. Domain Layer (src-tauri/src/domain/)¶
Reine Business-Logik, keine I/O-Operationen.
| Modul | Zweck |
|---|---|
parser.rs |
Parst Backlog.md → Rust-Structs |
renderer.rs |
Rendert Rust-Structs → Backlog.md |
validator.rs |
Validiert Zyklus-Freiheit, Referenzen |
models.rs |
Datenstrukturen (BacklogItem, Dependency, etc.) |
4. Repository Layer (src-tauri/src/repository/)¶
Daten-Zugriff auf SQLite.
| Modul | Zweck |
|---|---|
db.rs |
Connection Pool, Transaktions-Management |
project_repo.rs |
CRUD für Projekte |
items_repo.rs |
CRUD für Items |
migrations/ |
SQL-Migrations-Dateien |
Datenbank (SQLite)¶
Speicherort: .backlog-admin/backlog.db (pro Projekt)
Haupttabellen:
- projects: Projekt-Metadaten
- backlog_items: Alle Items (Features, Tasks, Bugs, Chores)
- dependencies: Graph-Kanten (from_item_id → to_item_id)
- acceptance_criteria: Akzeptanzkriterien (Checkboxen)
- tags: Tag-Definitionen
- item_tags: Item-Tag-Zuordnungen
- id_sequences: Auto-Increment pro Typ (F, T, B, C)
Siehe Datenbank-Schema für Details.
File Watcher¶
Technologie: notify-debouncer-full 0.3
Funktionsweise:
1. Überwacht docs/Backlog.md auf Änderungen
2. Debouncing: 500ms (ignoriert schnelle Mehrfach-Schreiboperationen)
3. Hash-Vergleich: Ignoriert Änderungen, die von der App selbst kommen
4. Trigger: Bei externer Änderung → Event an Frontend
Siehe File-Sync für Details.
Datenfluss¶
Write-Path (User → Backlog.md)¶
Read-Path (Backlog.md → User)¶
Deployment-Modell¶
Plattformen: - Windows (.msi Installer) - macOS (.dmg) - Linux (.deb, .AppImage)
Merkmale: - Offline-First: Keine Server-Komponente nötig - Single Instance: Pro Projekt eine SQLite-DB - Multi-Project: Mehrere Projekte parallel verwaltbar - Portable: Backlog.md ist weiterhin text-basiert, lesbar ohne App
Technologie-Entscheidungen¶
Warum Tauri statt Electron?¶
| Kriterium | Tauri | Electron |
|---|---|---|
| Binary-Größe | 3-5 MB | 120+ MB |
| Memory | ~50 MB | ~150+ MB |
| Sicherheit | Rust-Backend, explizite Permissions | Node.js-Backend |
| Performance | Nativ | Node.js-VM |
| File-Zugriff | Direkt via Rust | Node.js fs |
Entscheidung: Tauri für bessere Performance, kleinere Binary, native File-System-Integration.
Warum SQLite als Cache?¶
- Performant: Indexierte Queries für Filter/Suche
- Embedded: Keine Server-Installation nötig
- Transaktional: ACID-Garantien
- Portabel: Single-File Database
- Backlog.md bleibt Source of Truth: DB ist nur Cache/Index
Warum comrak für Markdown?¶
- Stricter als pulldown-cmark: Bessere CommonMark-Konformität
- Deterministisch: Gleiche Input → Gleiche Output
- Erweiterbar: GitHub-Flavored Markdown Support
Nächste Schritte¶
- Datenfluss - Detaillierte Sequence-Diagramme
- File-Sync - Hash-basierte Change Detection
- Datenbank - Vollständiges Schema
- Prozesse - Workflows und Best Practices