Architektur¶

Dieses Kapitel beschreibt die technische Architektur der easySale-Plattform.

Überblick¶

easySale verfolgt eine Single-Tenant Multi-Instance-Strategie mit einer geteilten Codebasis.
Jeder Kunde bekommt eine vollständig isolierte Instanz — die Entwicklung und Wartung des gemeinsamen Codes erfolgt zentral.

:material-domain: Multi-Tenant Architektur
Warum Single-Tenant? Wie funktioniert die Multi-Repo-Struktur? Build & Deployment.
:material-puzzle-edit: Client Override System
Wie werden kundenspezifische Anpassungen ohne Core-Änderungen realisiert?
:material-package-variant: Shared Packages
Gemeinsame Flutter-Packages: Models, Constants, Firebase-Utilities.

Kernprinzipien¶

1. Datenisolation (Single-Tenant)¶

Jeder Kunde hat eine eigene Firebase-Instanz. Es gibt keine geteilte Datenbank.
Das garantiert maximale Datensicherheit und DSGVO-Konformität.

Client-Repos referenzieren das Core-Repo als Git-Dependency:

# pubspec.yaml eines Client-Repos
dependencies:
  erp_system:
    git:
      url: git@github.com:Tech-Schuppen/easySale.git
      path: core/apps/erp_system
      ref: v1.2.0  # Fester Tag für Stabilität

3. Erweiterbarkeit ohne Fork¶

Kundenspezifische Features werden über das Client Override System realisiert — nie durch direkte Änderungen am Core.

4. Automatisches Update-Rollout¶

Ein Core-Bugfix löst automatisch Rebuilds bei allen Clients aus.
Kein manuelles Mergen für Standard-Updates.