Architektur

Von oben nach unten: Produktdomäne, Ökosystem und KI, eine Produktlinien-Schicht, dann Kernel und Designsystem. Firebase-Adapter werden im Composition Root gebunden.

• Produktdomänen-Schicht

  Nur vertikale Features, unter lib/features/<vertical>/ im jeweiligen Produkt-Repository: garage, patients, flights. Niemals in gemeinsamen Paketen.

• Ökosystem-Schicht

  After ID, After+, der Event-Bus, produktübergreifende APIs und gemeinsame Dienste. Produkte kommunizieren über dieses Fabric miteinander — nie über direkte Importe untereinander.

• KI-Funktionen

  Eine KI-Plattform mit modularen Funktionen — Konversation, OCR, Vision, Zusammenfassung, Tool Calling und mehr. Produkte aktivieren oder deaktivieren sie; eigene KI-Stacks liefern sie nicht aus.

• Consumer-Module

  Schlanke B2C-Schicht: Mitgliedschafts-Bridge, Consumer-Feature-Katalog, persönlicher Tresor, Einwilligung beim Start und regionaler Standort. Referenz: SuperGarage.

• Enterprise-Module

  Vierzehn B2B-Ports — Organisation, RBAC, Workflow, Aufgaben, Kalender, Dokumente, Messaging, Reporting, Audit, Offline-Sync — jeweils mit In-Memory-Mock. Referenz: SuperHospital.

• Gemeinsamer Kernel

  Auth, gehärtetes Networking, Speicher, Riverpod-DI, Flags, Remote Config, BYOK-KI-SDK, Premium-Berechtigungen, Benachrichtigungen, Deep Links sowie Dashboard-, Plugin-, Such- und Einstellungs-Engines.

• Designsystem

  Eine visuelle Familie für Consumer und Enterprise: Tokens für Farbe, Abstände, Radien, Motion und Typografie, dazu gemeinsame Komponenten.

• Firebase-Adapter

  Firebase Auth, Firestore-Blob-Sync und Storage-Mediensync hinter after_core-Ports. Nur im Composition Root gebunden; Domänencode importiert Firebase nie.

Abhängigkeiten zeigen nur nach unten. Produkte kommunizieren über Events und sichere APIs in der Ökosystem-Schicht miteinander. Eine neue Domäne fügt ein Modul in der obersten Schicht hinzu und lässt dieses Diagramm unverändert.

• SuperGarage ist die Consumer-Referenz; SuperHospital ist die Enterprise-Referenz.
• Branchen- und vertikale Module liegen nur in Produkt-Repositories.
• Gemeinsame OS-Module liegen nur in after_core, after_consumer und after_enterprise.
• Generieren statt neu anfangen.
• Ports statt SDKs.
• Das Familiengefühl gewinnt: Chrome, Motion, Dichte, Splash und Shell sind identisch.
• Jeder Port wird mit einer Mock-Implementierung ausgeliefert.

Jedes Produkt, ob Consumer oder Enterprise, startet über dieselbe Sequenz.

main.dart
  → PlatformConfig.current = manifest
  → ProviderScope(overrides: After*Overrides…)
  → ColdStart (OVERSTEIN splash)
       → AuthGate
            → ProductShell (tabs from platform + spec)
                 → Home = Dashboard Engine (+ plugins)
                 → OS modules = platform screens
                 → Vertical = product feature modules only