After Framework

Produkte auf einem gemeinsamen Betriebs-Framework bauen.

Einmal bauen. In jeder Domäne ausliefern.

After Framework gibt Produkten ein gemeinsames Fundament: Architektur, Identität, KI, Designsysteme, Tooling und wiederverwendbare Domänenmodule.

supercore/packages7 Pakete · 2 Produktlinien · 1 Kompositionsvertrag
SuperGarageAfterHubSuperHospitalafter_ecosystemafter_aiafter_consumerafter_enterpriseafter_firebaseafter_coreafter_design_system
Legende:pubspec-Abhängigkeitdokumentierter Referenz-Stack

01 · Framework-Architektur

Ein Kernel. Zwei Produktlinien. Schlanke Produkte obenauf.

Alle Produkte teilen dieselben Schichten. Eine neue Life Domain oder Industry Domain fügt oben ein Modul hinzu — die Schichten darunter bleiben unverändert.

Produktspezifisch

Gemeinsame Plattform

Adapter im Composition Root

Eine Schicht auswählen, um zu sehen, was sie verantwortet und wovon sie abhängt.

after_core

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.

Hängt ab von
Keine — Basisschicht
Verwendet von
Produktdomänen-Schicht · Ökosystem-Schicht · KI-Funktionen · Consumer-Module · Enterprise-Module · Designsystem · Firebase-Adapter

Gemeinsame Wiederverwendung, produktspezifisches Erlebnis

Die Plattformdoktrin zielt darauf ab, dass jedes Produkt neunzig Prozent oder mehr seiner Laufzeitfunktionen erbt. Ein Produkt verantwortet seine Domäne, vertikale Features, KI-Profil, Kataloge und Branding — sonst nichts.

Regeln, die das System tragen

  1. 01Ports statt SDKs: Vertikaler Code hängt von After-Schnittstellen ab, nie von Hersteller-SDKs.
  2. 02Vertikale Module liegen nur in Produkt-Repositories unter lib/features/.
  3. 03Jeder Port wird mit einem Mock ausgeliefert, damit Scaffolds ohne Backend laufen.
  4. 04Generieren statt neu anfangen: Neue Produkte starten aus einer Spec, nicht mit einer neuen Architektur.

02 · Produktfabrik

Von der Idee zum lauffähigen Produkt auf wiederverwendbarem Fundament.

Die Produktfabrik macht aus einer kleinen product.spec.yaml eine benachbarte Flutter-App, die von den gemeinsamen Paketen abhängt. Die Spec enthält nur, was das Produkt einzigartig macht.

  1. 01

    Idee

    Produkt benennen und eine Linie wählen: consumer oder enterprise, mit SuperGarage oder SuperHospital als Referenz.

  2. 02

    Domäne

    product.spec.yaml schreiben: Domäne, vertikale Features, Tabs, Berechtigungen, Dashboard-Widgets, KI-Skills, Branding, Locales.

  3. 03

    Module

    Alles, was nicht in der Spec steht — Auth, Mitgliedschaft oder Organisation, RBAC, Kalender, Aufgaben, Benachrichtigungen, Suche — wird geerbt.

  4. 04

    Produkt-Shell

    generate_product.ps1 erzeugt Manifest, Composition Root, Feature-Katalog, Shell, l10n-Dateien und einen CI-Workflow.

  5. 05

    Deployment

    Der generierte CI-Workflow führt bei jedem Push und Pull Request auf main Formatierung, Analyse und Tests mit Coverage aus.

Das Produkt verantwortet

  • Name, Paket, Bundle, Produktlinie
  • Vertikale Features und i18n-Keys
  • Navigations-Tabs
  • RBAC-Berechtigungsstrings
  • Dashboard-Widgets
  • KI-Skills und Tool-Bindings
  • Akzentfarbe und Monogramm

Die Plattform stellt bereit

  • Auth und Superadmin
  • Mitgliedschaft oder Organisation
  • RBAC-Engine und Audit-Log
  • Kalender, Aufgaben, Dokumente
  • Benachrichtigungen und Analytics
  • Workflow-, Dashboard- und Such-Engines
  • Designsystem, Splash, CI

Ein erneuter Generatorlauf mit weiterentwickelter Spec aktualisiert Gerüstdateien, ohne von Menschen geschriebenen Feature-Code zu zerstören.

03 · Pakete und Funktionen

Sieben Pakete. Explizite Abhängigkeiten.

Alle Pakete haben im supercore-Repository die Version 1.0.0 und werden über Pfadabhängigkeiten eingebunden. Ein Paket auswählen, um zu verfolgen, wovon es abhängt und was davon abhängt.

Gemeinsamer Kernel

after_core

Ports und Standardimplementierungen für Auth, Networking, Speicher, DI, Analytics, Feature Flags, Remote Config, KI, Benachrichtigungen, Deep Links und Premium-Berechtigungen. Produkte überschreiben Riverpod-Provider mit eigenen Adaptern.

Hängt ab von
Keine — Basisschicht
Verwendet von

Zentrale APIs

  • AppPlatformManifest
  • PlatformConfig
  • AfterStandardOverrides
  • AfterBootstrapMode
  • AfterAuthRepository
  • AfterApiClient
  • AfterHttpClientFactory
  • AfterFeatureFlags
  • AfterRemoteConfig
  • AfterAiCredentialVault

Wichtige Drittanbieter-Abhängigkeiten

flutter_riverpod · dio · flutter_secure_storage · shared_preferences · google_sign_in · app_links · flutter_local_notifications

after_ecosystemafter_aiafter_consumerafter_enterpriseafter_firebaseafter_coreafter_design_system

Beispiel

dart
import 'package:after_core/after_core.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:shared_preferences/shared_preferences.dart';

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
  final prefs = await SharedPreferences.getInstance();

  runApp(
    ProviderScope(
      overrides: [
        afterSharedPreferencesProvider.overrideWithValue(prefs),
        afterAuthRepositoryProvider.overrideWithValue(MyFirebaseAuthRepository()),
        afterAnalyticsProvider.overrideWithValue(MyFirebaseAnalytics()),
        // ... store-specific adapters
      ],
      child: const MySuperApp(),
    ),
  );
}

Quelle supercore/packages/after_core/README.md (öffnet in neuem Tab)

04 · CLI und Entwickler-Workflow

Skripte und Flutter-Befehle statt Magie.

Das Tooling liegt als PowerShell-Skripte in supercore/scripts, neben der Standard-Flutter-Toolchain. Ein separat paketiertes CLI-Binary gibt es nicht.

Initialisieren

Eine Spec ohne Flutter validieren, dann die benachbarte App generieren und bootstrappen.

validate_product_spec.ps1
powershell -File scripts\validate_product_spec.ps1 -SpecPath factory\specs\examples\super_airport.product.spec.yaml

Quelle supercore/factory/README.md (öffnet in neuem Tab)

generate_product.ps1
# From a spec
powershell -File scripts\generate_product.ps1 -SpecPath factory\specs\examples\super_airport.product.spec.yaml

# From a name only (quick starter)
powershell -File scripts\generate_product.ps1 -Name SuperAirport -Reference SuperHospital

# Preview without writing files
powershell -File scripts\generate_product.ps1 -SpecPath factory\specs\examples\super_airport.product.spec.yaml -DryRun

Quelle supercore/factory/README.md (öffnet in neuem Tab)

flutter
cd ..\superairport
flutter create .
flutter pub get
flutter analyze
flutter test

05 · Vom Framework zu echten Produkten

Gemeinsame Funktionen werden zu produktspezifischen Erlebnissen.

SuperGarage ist die ausgelieferte Consumer-Referenz. Jeder Screen unten ist ein echter Store-Screenshot; das Overlay zeigt, welche Teile von der Plattform stammen und welche das Produkt verantwortet.

SuperGarage-Screenshot: Fahrzeug-Gesundheitswert und Erinnerungen im Garagen-Dashboard.

SuperGarage-Funktionskarte

Von supergarage/lib importierte Bezeichner, gruppiert nach verantwortendem Paket.

after_core

  • AfterUserPlan
  • AfterAiCredentialVault
  • AfterLocalNotifications

after_consumer

  • FamilyShellHeader
  • AfterRegionalLocation

after_firebase

  • AfterFirebaseBootstrap

Produkt-Features

  • features/vehicle
  • features/maintenance
  • features/obd
  • features/expenses
  • features/fleet
  • features/trips
  • features/assistant
  • features/community

Produktfamilie

Status laut supercore/catalog/products.yaml. Nur SuperGarage ist als ausgeliefert markiert.

  • SuperGarage-Symbol

    SuperGarage

    Consumer · Referenz

    Mobilität: Fahrzeuge, Wartung, Versicherung, Kraftstoff, OBD, Flotte

    after_core · after_design_system · after_firebase · after_consumer

  • AfterHub-Symbol

    AfterHub

    Consumer · OS-Shell

    Consumer-OS-Shell: Identität, Dashboard, KI, Kalender, Suche, After+

    Gerüst

    after_ai · after_consumer · after_core · after_firebase · after_design_system · after_ecosystem

  • SuperHospital-Symbol

    SuperHospital

    Enterprise · Referenz

    Krankenhausbetrieb — Enterprise-Referenz

    Gerüst
  • SuperHealth-Symbol

    SuperHealth

    Consumer

    Persönliche Gesundheit: Medikamente, Akten, Schlaf, Ernährung

  • SuperFinance-Symbol

    SuperFinance

    Consumer

    Private Finanzen: Abos, Budgets, Investments

    Gerüst
  • SuperHome-Symbol

    SuperHome

    Consumer

    Immobilie und Haushalt: Wartung, Versorger, Garantien

    Gerüst
  • SuperTravel-Symbol

    SuperTravel

    Consumer

    Reisen: Trips, Flüge, Hotels, Reisepläne

    Gerüst
  • SuperPet-Symbol

    SuperPet

    Consumer

    Haustiere: Tierarzt, Futter, Gesundheitsakten

    Gerüst
  • SuperNews-Symbol

    SuperNews

    Consumer

    KI-personalisierte Nachrichten mit Zusammenfassungen

  • SuperSports-Symbol

    SuperSports

    Consumer

    Sport und Leistung: Fitness, Ergebnisse, Spielpläne

  • SuperAirport-Symbol

    SuperAirport

    Enterprise

    Flughafenbetrieb: Flüge, Gates, Start- und Landebahnen

    Gerüst
  • SuperMaritime-Symbol

    SuperMaritime

    Enterprise

    Hafen- und Schiffsbetrieb

    Gerüst
  • SuperFactory-Symbol

    SuperFactory

    Enterprise

    MES und Wartung in der Fertigung

    Gerüst
  • SuperFarm-Symbol

    SuperFarm

    Enterprise

    Landwirtschaft: Anbau, Viehbestand, Maschinen

    Gerüst

06 · Designsystem

Konsistenz ohne Gleichförmigkeit.

after_design_system gibt jedem Produkt dasselbe Chrome, dieselbe Dichte und Motion. Produkte ändern Akzent, Monogramm, Features und Texte — nicht das System.

Tokens

Farbe, Abstände, Radien und Motion sind Dart-Konstanten, gemeinsam für Consumer und Enterprise.

Farbe

  • accent#38BDF8
  • accentDeep#0284C7
  • graphite950#0B0C0F
  • graphite800#222831
  • steel#8A919D
  • lightBackground#FAFBFC
  • success#22C55E
  • warning#F59E0B
  • danger#EF4444

Abstände · 4pt-Raster

  • xs4
  • sm8
  • md12
  • lg16
  • xxl24
  • xxxl32
  • massive48
  • hero64

Radius

  • 6
  • 8
  • 12
  • 16
  • 20

Motion

  • instant100ms
  • fast · micro180ms
  • normal · page280ms
  • slow · modal420ms
  • emphasis560ms

Komponenten

Buttons, Karten, Eingabefelder, Navigation, Dialoge, Diagramme, Dashboard, Leer- und Ladezustände, Einstellungsbereiche und die obere Shell-Leiste.

  • buttons.dart
  • cards.dart
  • inputs.dart
  • navigation_bar.dart
  • dialogs.dart
  • charts.dart
  • dashboard.dart
  • empty_states.dart
  • loading.dart
  • settings_section.dart
  • shell_top_bar.dart

Barrierefreiheit

Helle und dunkle Farbschemata werden gemeinsam ausgeliefert. Diagrammreihen sind so geordnet, dass sie unterscheidbar bleiben, und Motion-Tokens halten Übergänge kurz und zielgerichtet.

Responsives Verhalten

Seitenränder und Inhaltsbreite passen sich über AfterSpacing an die Viewport-Breite an.

Viewport-BreiteMax. InhaltsbreiteSeitenrand
< 360width14 / 10 / 14 / 28
360 – 41952016 / 12 / 16 / 28
420 – 71964020 / 12 / 20 / 28
≥ 72076020 / 12 / 20 / 28

Markenerweiterung

Jede Produkt-Spec deklariert Akzent und Monogramm. Das Theme übernimmt den Akzent über accentOverride; alles andere bleibt in der Familie.

  • SuperGarage#22D3EE
  • SuperKids#F472B6
  • SuperHospital#F43F5E
  • SuperFactory#F59E0B

07 · Dokumentation

Dokumentation zum schnellen Erfassen.

Jede Seite ist aus dem supercore-Repository abgeleitet und verlinkt auf ihre Quelldatei.

  • Sofortsuche per Tastenkürzel
  • Mitlaufendes Inhaltsverzeichnis mit Deep Links
  • Kopier-Buttons und Syntaxhervorhebung in beiden Themes
  • Paketseiten mit Abhängigkeitsgraphen
  • Architekturdiagramme mit statischen Fallbacks
  • In zehn Sprachen verfügbar, mit Rechts-nach-links-Unterstützung
Dokumentation öffnen

08 · Enterprise-Grenzen

Grenzen, die im Fehlerfall schließen.

Enterprise-Isolation wird im Code erzwungen und in Architecture Decision Records festgehalten.

  • Fail-Closed-Mandanten

    Organisationsbezogene Enterprise-Ports erfordern einen EnterpriseScope. Fehlt die organizationId, wird ein Fehler geworfen — nie werden alle Mandanten zurückgegeben.

  • Berechtigung vor Persistenz

    Vertikale Features prüfen PermissionSet.allows(...) vor jedem ändernden Aufruf. Produkte deklarieren ihre eigenen Berechtigungsstrings.

  • Append-only-Audit

    Jede ändernde Enterprise-Aktion muss einen AuditLogEntry an das Append-only-AuditLogRepository anhängen.

  • Nur sichere Interop

    Produktübergreifende Aufrufe laufen über AfterSecureInteropBridge: After-ID-Audience, Scopes, RBAC und Org-Mitgliedschaft, dann ein verpflichtender Audit-Eintrag.

  • Fail-Fast-Bootstrap

    Im Produktionsmodus wirft ein fehlender Adapter beim Start einen Fehler, sodass Mock-Provider nicht unbemerkt in Produktion gelangen.

  • Modular von Grund auf

    Echte Backends ersetzen MockEnterpriseRepository im Composition Root. Die OS-Schicht erfährt nie den Namen des Anbieters.

enterprise_scope.dart
/// Fail-closed tenant + actor context for enterprise ports (ADR-002).
class EnterpriseScope {
  final String organizationId;
  final String actorId;
  final PermissionSet permissions;

  /// Throws if [organizationId] is missing/blank — never allow all-tenant lists.
  static String requireOrganizationId(String? organizationId) {
    final id = organizationId?.trim() ?? '';
    if (id.isEmpty) {
      throw StateError(
        'EnterpriseScope: organizationId is required (fail-closed tenancy).',
      );
    }
    return id;
  }
}

Quelle supercore/packages/after_enterprise/lib/src/scope/enterprise_scope.dart (öffnet in neuem Tab)

Dies sind im supercore-Repository dokumentierte Architekturkontrollen. After Framework erhebt keinen Anspruch auf Zertifizierung oder regulatorische Konformität.

Enterprise-Grenzen

Das Produkt kleiner. Das Fundament stärker.

Mit der Architektur beginnen, die Paketdoku lesen oder den Quellcode erkunden.