Abläufe

Status: Entwurf · Spec-Kandidat: ja

Hier sind die zentralen Abläufe als Sequenzdiagramme dokumentiert. Jeder Use Case aus Anwendungsfälle sollte vor Implementierung um ein eigenes Diagramm und eine Detail-Spec erweitert werden.

Verbindliche Reihenfolge in einer Mutationstransaktion

Jeder schreibende Service-Aufruf (Insert/Update/Archive/Restore/Soft-Delete/Relate/Unrelate) folgt strikt dieser Reihenfolge in einer DB-Transaktion:

BEGIN
  1. Tenant-Kontext setzen           -- aus JWT/Header, siehe 70-security/02-authorization.md
  2. Authorization-Check             -- mdm.v_effective_permission(principal, action, target)
                                     -- bei deny: 403, AA_AUDIT_LOG mit action='access_denied', kein Outbox
  3. Validierung                     -- required, types, unique_per_type, validation_rule, delete_policy
  4. INSERT/UPDATE DDM_ENTITY (oder DDM_ENTITY_RELATION)
                                     -- Trigger trg_entity_before_write: search_vector, version++, updated_at
  5. INSERT DDM_ENTITY_VERSION           -- Snapshot mit version_no = DDM_ENTITY.version
  6. INSERT AA_AUDIT_LOG                -- action, actor_principal_id, before/after, correlation_id
  7. INSERT AA_OUTBOX_EVENT             -- aggregate_id, event_type, payload, audit_log_id, correlation_id
COMMIT

Pflichten:

• Schritte 4–7 sind immer im selben Statement-Batch / derselben Transaktion. Kein Schreibpfad darf einen davon auslassen.
• Audit (6) und Outbox (7) sind kein “Best-Effort”-Anhang: ihr Fehlschlagen rollt die fachliche Mutation zurück.
• Trigger erledigen Teile von 4 automatisch (search_vector, version-Increment) — Service-Code setzt diese Felder nicht.
• Bei access_denied in Schritt 2 wird nur ein AA_AUDIT_LOG-Eintrag geschrieben (eigene Transaktion möglich, da fachlich nichts zu rollback’en); kein Outbox-Event.
• correlation_id aus X-Correlation-Id-Header (oder neu generiert) ist auf AA_AUDIT_LOG und AA_OUTBOX_EVENT derselben Operation identisch.

Anlage einer Entität (UC-03)

sequenceDiagram
    participant User as Benutzer
    participant UI as Frontend
    participant API as Service-Layer
    participant DB as PostgreSQL

    User->>UI: Entität anlegen
    UI->>API: POST /entities
    API->>DB: Lade entity_type
    API->>DB: Lade entity_type_attribute
    API->>API: Validierung gegen Metadaten
    API->>DB: INSERT entity
    API->>DB: INSERT audit_log
    API-->>UI: 201 Created
    UI-->>User: Entität erfolgreich angelegt

Hinweise:

• Schritt „INSERT entity” löst trg_entity_before_write aus → setzt updated_at, berechnet search_vector, lässt version für INSERT auf 1.
• INSERT AA_AUDIT_LOG läuft in derselben Transaktion wie der Entity-Insert.
• Optional: INSERT DDM_ENTITY_VERSION (version_no = 1, snapshot = ...).

Weitere Abläufe (zu spezifizieren)

Ablauf	Bezugs-UC
Anlage Entitätstyp	UC-01
Definition Attribute	UC-02
Anlage Beziehung	UC-04
Strukturierte Suche / Filter	UC-05
Archivierung mit Abhängigkeiten	UC-06
SQL-Auswertung (BI-Pfad)	UC-07
Soft Delete einer Entität	– (Querschnitt)
Wiederherstellen einer archivierten Entität	–
Hard Delete (administrativ)	–
Bidirektionale Beziehung anlegen	–

Diese Abläufe sind später jeweils mit einem eigenen Sequenzdiagramm und Akzeptanztest zu hinterlegen.

Verwandte Dokumente

• Anwendungsfälle
• Validierung
• Audit und Historisierung
• Löschen und Archivierung