Init: RoggioApp Architecture, Prisma Schema, API MVP

2026-04-26 19:42:42 +02:00
commit 193b29e8a9
5256 changed files with 1446953 additions and 0 deletions
@@ -0,0 +1,46 @@
+# RoggioApp - Die Ultimative Abstraktion (Einheiten & Eigenschaften)
+
+## 1. Die physische Welt ist ein Graph aus "Einheiten" (Units)
+Es gibt keine festen, harten Tabellen wie `Wohnungen`, `Räume` oder `Parkplätze`.
+Alles ist eine grundlegende **Unit** (Einheit) auf dem Gelände.
+
+### Was definiert eine Unit?
+Eine Unit ist lediglich ein Knotenpunkt (Node), der über seine Eigenschaften (Properties/Traits) und seine Verbindungen (Parent/Child) definiert wird.
+
+**Beispiele für Einheiten (Units):**
+*   Das Grundstück selbst (Unit)
+*   Das Haus A (Unit, liegt auf dem Grundstück)
+*   Ein Zirkuswagen (Unit)
+*   Ein Badezimmer (Unit, liegt in Haus A)
+*   Ein Stück Rasen (Unit)
+
+### Die Eigenschaften (Traits / Properties)
+Was die Unit *ist* oder was man mit ihr *tun* kann, wird über zugewiesene Eigenschaften bestimmt:
+*   `is_rentable` (RentalUnit): Die Einheit kann gebucht werden (z.B. Wohnung, Zirkuswagen, Veranstaltungsraum, Parkplatz).
+*   `needs_service` (Serviceable): Die Einheit erfordert Reinigung oder Instandhaltung (gilt für Mietobjekte, aber eben auch für Flure oder den privaten Putzraum).
+*   `has_capacity` (Capacity): Definiert, wie viele Schlafplätze (oder Sitzplätze beim Veranstaltungsraum) sich durch die Untereinheiten ergeben.
+
+## 2. Die Akteure (Personen & Gruppen)
+Auch hier wird stark normalisiert, um Doppelungen bei den Personendaten zu vermeiden (z.B. wenn Peter dieses Jahr mit Familie A kommt und nächstes Jahr mit Verein B).
+
+*   **Person (Die Basis):**
+    *   *Eindeutig / Fest:* Vorname, Nachname, Geburtsdatum, Ausweisnr., Mail, Mobil, Foto.
+    *   *Kategorisierung (Eigenschaft):* Ist diese Person Kollektiv-Mitglied, Support-Gang, Personal oder Gast/Kunde? (Kann sich überlappen!).
+*   **Adresse (Die Location):**
+    *   *Nicht eindeutig / Shared:* Straße, Hausnummer, PLZ, Stadt, Land. (Mehrere Personen können dieselbe Adresse referenzieren).
+*   **Gruppe (Die Entität, die bucht):**
+    *   Besteht aus $N$ Personen.
+    *   *Variabel:* Person X kann Mitglied in Gruppe A (Familienurlaub) und Gruppe B (Yoga-Retreat) sein.
+
+## 3. Die Transaktionen (Buchungen & Aktionen)
+*   **Buchungen (Bookings):**
+    *   Verbinden eine **Gruppe** mit einer **RentalUnit** (Unit mit `is_rentable=true`) über einen bestimmten Zeitraum.
+*   **Aktionen (Tasks / Operations):**
+    *   Putzen, Einkaufen, Abholen.
+    *   Können an eine Buchung geknüpft sein (Endreinigung nach Gruppe A).
+    *   Oder an eine Unit (Grundreinigung des Flurs, der `needs_service` ist, aber nicht `is_rentable`).
+
+## Claras architektonische Ableitung
+Das ist ein Entity-Component-System (ECS) oder ein Node-Graph, wie man ihn aus Game-Engines oder extrem skalierbaren ERP-Systemen kennt! 
+Statt 20 verschiedener Tabellen (`flats`, `rooms`, `parking_spaces`) bauen wir einen großen `units`-Baum. Was die Unit kann, bestimmt eine Verknüpfungstabelle `unit_traits`. 
+Das macht das System zukunftssicher: Wenn ihr morgen beschließt, Surfbretter zu verleihen, legt ihr einfach neue Units an, gebt ihnen den Trait `is_rentable` (RentalUnit) und sie tauchen sofort im Buchungskalender auf, ohne dass das Datenbankschema geändert werden muss.