# 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.