Arbeitsdetail

Das Problem

Geschäftsverwaltungsanwendungen wachsen oft ungeordnet:

• verstreute Geschäftslogik,
• undokumentierte implizite Regeln,
• Endpoints, die direkt an Modelle gekoppelt sind,
• Schwierigkeit, Änderungen einzuführen ohne bestehende Flows zu brechen.

Außerdem erfordern Operationen wie:

• Bestätigung von Einkäufen oder Verkäufen,
• Lagerbewegungen,
• Cash-Bewegungen,
• Backups und Wiederherstellungen,

Kontrolle, Nachverfolgbarkeit und Schutz, nicht nur einfache CRUDs.

Die Lösung

Ich habe eine API mit einer streng gesteuerten Architektur entworfen, in der jede Verantwortung klar abgegrenzt und dokumentiert ist.

Schichtenarchitektur

Explizite und nicht verhandelbare Trennung der Verantwortlichkeiten:

• Model Repräsentiert die Datenbankstruktur und die Serialisierung (to_dict).
• Service Enthält die Geschäftslogik und operativen Regeln.
• Controller Verarbeitet Daten, Validierungen und orchestriert Aufrufe.
• API / Router Definiert Endpoints und den API-Vertrag.

Wenn etwas sich ändert, berührt man eine einzige Schicht, nicht das gesamte System.

Basis + Erweiterungen Architektur

Eine der zentralen Erkenntnisse dieses Projekts ist die Verwendung einer Basis + Spezialisierung-Architektur:

• BaseModel
  • id
  • Audit (created_at, updated_at)
  • Soft Delete (is_active, deleted_at)
  • to_dict()
• Reale Modelle erben, erweitern oder überschreiben nur das Notwendige.

Das Gleiche gilt für:

• BaseService
• BaseController
• BaseRouter

Die das Standard-CRUD implementieren:

• create
• get_all
• get_by_id
• update
• delete (soft delete)
• restore

Und die sich anschließend gemäß den dokumentierten Geschäftsregeln spezialisieren.

• Konsistenz im gesamten Projekt,
• weniger Duplikation,
• kontrollierte Evolution.

Domäne und konzeptionelles Modell (informelles DDD)

Während der Entwicklung stellte ich fest, dass ich natürlich eine informelle DDD-Architektur anwende:

• Entities
  • users
  • products
  • customers
  • suppliers
• Aggregates
  • stock locations
  • Stock pro Produkt
  • cash accounts
• Documents
  • Einkaufs-Lieferscheine
  • Verkaufs-Lieferscheine
  • Lager-Einlagerungen
  • Cash-Transfers
• Events
  • Lagerbewegungen
  • Cash-Bewegungen

Dokumente sind nicht nur Daten: Sie repräsentieren Aktionen, die die Aggregates über Events beeinflussen.

Hauptfunktionalität

Geschäftsverwaltung

• Benutzer und Rollen (ADMIN / USER)
• Produkte, Kunden und Lieferanten

Lager

• Standorte
• Bestand pro Standort
• Einlagerungen zwischen Standorten

Cash

• Kassenkonten
• Transfers und Bewegungen

Geschäftsdokumente

• Einkaufs-Lieferscheine
• Verkaufs-Lieferscheine
• Dokumentenbestätigung
• Explizite Regeln nach Status (DRAFT / CONFIRMED)

Sicherheit, Rollen und Zugriffskontrolle

• Authentifizierung via JWT (access + refresh)
• Tokens enthalten password_changed_at
• Automatische Token-Invaliderung nach Passwortänderung

Rollen:

• ADMIN
  • Benutzerverwaltung
  • Backups und Restores
  • kritische Operationen
• USER
  • standardmäßige Geschäftsoperationen

Explizite Sicherheitsregeln:

Ein Benutzer kann sich nicht selbst löschen und nicht den letzten Admin entfernen.

Backups und Datensicherung

Das System bietet explizite Unterstützung für Backups:

• Vollständiger Datenbankexport via Endpoint
• Wiederherstellung aus Backup
• Dedizierter Service für diese Operationen

Datenschutz ist Teil des Designs, nicht eine spätere Ergänzung.

Technischer Stack

• Sprache: Python
• Framework: Flask (WSGI)
• Datenbank: SQLite
• ORM: SQLAlchemy
• Authentifizierung: JWT
• Testing: pytest, pytest-cov
• CORS: Flask-Cors
• Konfiguration: python-dotenv

Betrieb und Deployment

• Backend auf PythonAnywhere deployed
• Operatives Update im Repo dokumentiert
• SQLite-Datenbank in Produktion
• System läuft und ist öffentlich erreichbar

🔗 API in Produktion

🔗 GitHub-Repository

Ursprung des Arbeitssystems

Dieses Projekt ist eines der ersten, in dem ich begann, den Einsatz von KI in der Entwicklung zu formalisieren.

Der Ordner docs/ enthält:

• Architekturverträge,
• explizite Regeln für den KI-Einsatz,
• Basisvorlagen,
• Fehlerkataloge,
• Dokumentation als Quelle der Wahrheit.

Hier erscheinen bereits Konzepte, die später zu Folgendem evolvierten:

• gesteuerte Arbeit,
• formaler Abschluss von Entscheidungen,
• Rollentrennung,
• und schließlich der Ansatz PDCA + orchestrator / executor, den ich heute nutze.

Was dieses Projekt zeigt

Dieses Projekt zeigt meine Fähigkeit,:

• Entwurf komplexer Backends mit realen Geschäftsregeln
• Bau gesteuerter und erweiterbarer Architekturen
• Anwendung von Prinzipien nahe DDD
• Integration von Sicherheit, Kontrolle und Nachverfolgbarkeit
• Betrieb von Software in Produktion
• Weiterentwicklung zu einem reproduzierbaren und kontrollierten Arbeitssystem

Projektbilder