PMFA Standardisierung

Registrierungsgesteuertes Design

PMFA verwendet Registrierungen, um Schemas zu definieren, Konsistenz durchzusetzen und UI-Generierung zu automatisieren — wodurch manuelle Codierung für Routineoperationen eliminiert wird.

Das Problem mit traditioneller Software

In den meisten Systemen erfordert das Hinzufügen einer neuen Entität (z.B. "Produktkategorie"):

  1. Schreiben des Datenbankschemas (SQL-Migrationen)
  2. Schreiben der Backend-Validierungslogik
  3. Schreiben von API-Endpunkten (create, read, update, delete)
  4. Schreiben von Frontend-Formularen und Tabellen
  5. Schreiben von Tests für all das oben Genannte

Dies ist langsam, fehleranfällig und erzeugt Inkonsistenzen zwischen Schichten.

Der PMFA-Ansatz: Registrierungen

In PMFA definieren Sie die Entität einmal in einer Registrierung. Das System generiert alles andere automatisch.

Beispiel: Definition einer "Material"-Entität

{
  "entity": "material",
  "label": "Material",
  "description": "Rohstoffe oder Komponenten für die Produktion",
  "fields": [
    {
      "name": "name",
      "type": "text",
      "label": "Materialname",
      "required": true,
      "max_length": 100
    },
    {
      "name": "supplier",
      "type": "ref:supplier",
      "label": "Lieferant",
      "required": true
    },
    {
      "name": "batch_number",
      "type": "text",
      "label": "Chargen-/Losnummer",
      "required": false
    },
    {
      "name": "quantity",
      "type": "decimal",
      "label": "Menge auf Lager",
      "required": true,
      "min": 0
    },
    {
      "name": "unit",
      "type": "enum",
      "label": "Maßeinheit",
      "options": ["kg", "liter", "piece", "meter"],
      "required": true
    }
  ],
  "authority_required": "warehouse.create_material"
}

Was automatisch geschieht

Aus dieser einzelnen Definition generiert PMFA:

  • Datenbankschema: Faktenspeicher mit korrekten Typen
  • Validierungslogik: Pflichtfelder, Min/Max, Enum-Prüfungen
  • API-Endpunkte: Create, read, query, mutate, revoke
  • UI-Formulare: Eingabefelder mit Labels und Validierung
  • UI-Tabellen: Listenansichten mit Sortierung und Filterung
  • Autoritätsprüfungen: Nur Benutzer mit "warehouse.create_material" können erstellen

Null manuelle Codierung.

Registrierung als Quelle der Wahrheit

Die Registrierung ist keine Dokumentation. Sie ist das System.

Wenn Sie die Registrierung ändern (z.B. ein Feld hinzufügen, ein Label ändern), passt sich das gesamte System an:

  • Formulare aktualisieren sich automatisch
  • API-Schema wird aktualisiert
  • Validierungsregeln ändern sich
  • Beweisexporte enthalten das neue Feld

Dies eliminiert die Diskrepanz zwischen "was die Docs sagen" und "was der Code macht".

Registrierungsversionierung

Registrierungen selbst werden als unveränderliche Tatsachen gespeichert. Wenn sich ein Schema ändert:

  • Eine neue Version der Registrierung wird erstellt
  • Alte Tatsachen bleiben unter ihrem ursprünglichen Schema gültig
  • Neue Tatsachen verwenden das neue Schema
  • Beweisexporte enthalten Schemaversionsinformationen

Dies stellt sicher, dass alte Daten auch dann interpretierbar bleiben, wenn sich Schemas weiterentwickeln.

Warum das wichtig ist

Geschwindigkeit

Das Hinzufügen einer neuen Entität dauert Minuten, nicht Tage. Keine Notwendigkeit, Backend-, Frontend- und Datenbankänderungen zu koordinieren.

Konsistenz

Alle Schichten (Datenbank, API, UI) sind garantiert synchron, weil sie aus derselben Quelle generiert werden.

Überprüfbarkeit

Schemaänderungen werden als Tatsachen verfolgt. Sie können sehen, wann ein Feld hinzugefügt wurde, von wem und warum.

Korrektheit

Validierungslogik wird aus dem Schema abgeleitet, nicht manuell geschrieben. Reduziert Bugs und Randfälle.

Praxisbeispiel: WorkshopOS

WorkshopOS definiert ~20 Entitäten in seiner Registrierung:

  • Arbeitsaufträge, Kunden, Materialien, Lieferanten
  • Rechnungen, Zahlungen, Gutschriften
  • Benutzer, Rollen, Berechtigungen

Die gesamte UI (Formulare, Tabellen, Filter) wird aus diesen Registrierungen generiert. Wenn ein Feld hinzugefügt wird (z.B. "Lieferadresse" bei Arbeitsaufträgen), wird das Formular automatisch auf allen Bildschirmen aktualisiert.

Einschränkungen

Registrierungsgesteuertes Design funktioniert am besten für:

  • CRUD-Operationen (create, read, update, delete)
  • Standardvalidierungen (required, min/max, enums)
  • Einfache Beziehungen (one-to-many, many-to-one)

Komplexe Geschäftslogik (z.B. mehrstufige Genehmigungsworkflows, benutzerdefinierte Berechnungen) erfordert immer noch Code. Aber 80% der Routineoperationen können registrierungsgesteuert sein.

Architektur → Beweismodell →