sebi/effigenix
1
0
Fork 0
mirror of https://github.com/s-frick/effigenix.git synced 2026-03-28 10:09:35 +01:00
Code Issues Releases Activity Actions
effigenix/backend/docs/tickets/003-review-batch-block-reason-persistence.md
Sebastian Frick d963d7fccc fix(inventory): Audit-Logging, testbare Zeitlogik und defensive Null-Prüfung für blockBatch/unblockBatch 
- AuditEvents STOCK_BATCH_BLOCKED/UNBLOCKED hinzugefügt, reason wird als Audit-Details geloggt
- LocalDate.now() aus Stock.unblockBatch() entfernt, referenceDate als Parameter (Application Layer übergibt)
- Defensive Null-Prüfung für expiryDate in unblockBatch MHD-Check
- Ticket 003 erstellt zur Klärung ob reason im Domain-Model persistiert werden soll
2026-02-20 00:17:03 +01:00

1.8 KiB
Raw Permalink Blame History

Ticket 003 – Prüfung: Sperr-Grund (reason) im Domain Model persistieren?

Datum: 2026-02-20 Commit: e7c3258 (feat(inventory): Charge sperren/entsperren) Status: Offen

Kontext

Beim Code-Review von blockBatch/unblockBatch wurde festgestellt, dass der reason-Parameter (Sperr-Grund) zwar über die API entgegengenommen und validiert wird (@NotBlank), aber aktuell nur im Audit-Log als details gespeichert wird – nicht im Domain Model selbst.

Das DDD-Modell (docs/mvp/ddd/07-inventory-bc.md, Zeile 63) sieht die Signatur blockBatch(StockBatchId batchId, String reason) vor, d.h. der reason war ursprünglich als Teil der Domain-Logik geplant.

Zu klären

  1. Soll reason in StockBatch persistiert werden?

    • Pro: Direkt abfragbar ohne Audit-Log-Suche, fachlich sichtbar im Bestandsüberblick
    • Contra: Audit-Log reicht für Nachvollziehbarkeit (HACCP/GoBD), zusätzliches Feld = Schema-Migration

  2. Falls ja: als optionales Feld blockReason in StockBatch?

    • Nur gesetzt wenn status == BLOCKED
    • Wird bei unblockBatch auf null zurückgesetzt
    • Erfordert: Liquibase-Migration, JPA-Entity-Anpassung, Mapper-Update

  3. Domain-Event StockBatchBlocked(StockId, StockBatchId, String reason)?

    • Das DDD-Modell (Zeile 302) sieht dieses Event vor
    • Aktuell keine Domain-Event-Infrastruktur implementiert → separates Thema

Aktuelle Lösung

reason wird im Audit-Log via AuditLogger.log(STOCK_BATCH_BLOCKED, batchId, "Reason: " + reason, actorId) festgehalten. Damit ist die HACCP-Compliance gewährleistet.

Empfehlung

Kurzfristig reicht der Audit-Log-Ansatz. Mittelfristig (wenn Chargen-Sperrgrund in der UI angezeigt werden soll) sollte blockReason als optionales Feld in StockBatch aufgenommen werden.