Definisci convenzione audit sulle tabelle

This commit is contained in:
2026-06-30 17:03:08 +02:00
parent a9c73fdfba
commit b12eab7aa6
2 changed files with 55 additions and 0 deletions

View File

@@ -4,6 +4,32 @@ Il modello deve essere abbastanza generale da non ripetere i limiti del legacy,
## Entita' principali
## Convenzione audit comune
Tutte le tabelle persistenti di dominio devono avere un blocco audit standard.
Campi minimi:
- created_by;
- created_at;
- updated_by;
- updated_at;
- deleted_by;
- deleted_at.
Questa forma e' volutamente esplicita per rendere semplice interrogare il database anche senza passare dall'applicazione.
Le cancellazioni fisiche devono essere evitate nelle tabelle operative. La regola di default e' il soft delete:
```text
deleted_at valorizzato = record cancellato logicamente
deleted_at nullo = record attivo
```
Per tabelle molto semplici o di sistema si puo' valutare una convenzione piu' compatta, ma il default del progetto resta il blocco audit esplicito.
Quando serve ricostruire la sequenza completa degli eventi, il blocco audit della riga non basta. In questi casi si usa anche AuditEvent, che registra azione, utente, timestamp, origine, valori prima/dopo e riferimento alla transazione.
### LogisticUnit
Rappresenta una qualsiasi unita' fisica movimentabile.

View File

@@ -229,6 +229,35 @@ Ogni azione che cambia stock, stato o configurazione deve registrare:
Questo e' indispensabile per produzione, assistenza e consulenza.
### Campi audit standard su tutte le tabelle
Tutte le tabelle persistenti di dominio devono adottare un blocco audit comune.
Forma consigliata:
- created_by;
- created_at;
- updated_by;
- updated_at;
- deleted_by;
- deleted_at.
Questa forma e' piu' leggibile di soluzioni troppo sintetiche come un singolo campo JSON di audit.
Il vantaggio e' che ogni tabella resta interrogabile direttamente con SQL semplice, anche durante assistenza, debug o migrazione.
Le cancellazioni devono essere logiche, non fisiche, salvo casi tecnici molto controllati.
Un record con deleted_at valorizzato e' considerato cancellato.
Un record con deleted_at nullo e' considerato attivo.
Questo blocco audit non sostituisce AuditEvent.
Il blocco audit serve a sapere lo stato amministrativo corrente della riga.
AuditEvent serve invece a ricostruire la sequenza storica completa delle operazioni.
## Entita' teoriche di supporto
Oltre alle entita' operative elencate sotto, il modello dovra' prevedere almeno queste entita' di supporto, anche se alcune possono essere minime nell'MVP: