Il confine che l’architettura deve proteggere
Una richiesta passa da opportunità a ordine e poi a ticket operativo. Ogni piattaforma ha uno stato chiamato chiuso, ma con significati e momenti differenti. Uno stato end-to-end non può essere posseduto contemporaneamente da CRM, gestionale e ticketing: ciascun sistema deve governare il proprio tratto e pubblicare eventi interpretabili.
Nel perimetro «assegnare ownership a stati e transizioni, non solo ai record», il confine passa da «evento che crea la transizione»: qui una responsabilità, un permesso o un’interpretazione diventano stato operativo. Usa una singola richiesta per distinguere stato locale, stato composto e vista per l’operatore.
I componenti, spiegati attraverso state machine, event contract, correlation ID e reconciliation view
Il componente responsabile di «sistema autorizzato a cambiare lo stato» dichiara input, output e risposta a «sincronizzare etichette omonime». Questo contratto precede la scelta della piattaforma e può diventare un test autonomo; nel perimetro descritto conta «sincronizzare etichette omonime».
Evento che crea la transizione
Il componente deve esporre questo confine. Il componente responsabile di «evento che crea la transizione» espone «sistema autorizzato a cambiare lo stato» nel proprio contratto e ferma il flusso in presenza di «sincronizzare etichette omonime».
Sistema autorizzato a cambiare lo stato
Il contratto non può lasciarlo implicito. Il componente responsabile di «sistema autorizzato a cambiare lo stato» espone «stati locali e stato condiviso» nel proprio contratto e ferma il flusso in presenza di «sovrascrivere stati più recenti».
Stati locali e stato condiviso
Qui si decide che cosa può proseguire. Il componente responsabile di «stati locali e stato condiviso» espone «gestione di annullamenti e riaperture» nel proprio contratto e ferma il flusso in presenza di «perdere la motivazione della transizione».
Gestione di annullamenti e riaperture
Questo controllo appartiene al livello che possiede il dato. Il componente responsabile di «gestione di annullamenti e riaperture» espone «evento che crea la transizione» nel proprio contratto e ferma il flusso in presenza di «nessun owner per le anomalie».
Il flusso end-to-end
Durante «costruire una macchina a stati comune» nasce l’identità del caso; «mappare transizioni e attori» cambia lo stato senza perderla. Separare questi due passaggi permette di sostituire il meccanismo senza ridefinire assegnare ownership a stati e transizioni, non solo ai record.
- 1
Costruire una macchina a stati comune
Il passaggio «costruire una macchina a stati comune» accetta un input definito e restituisce «evento che crea la transizione» con provenienza. Il contratto gestisce «sincronizzare etichette omonime» prima di invocare «mappare transizioni e attori».
- 2
Mappare transizioni e attori
Il passaggio «mappare transizioni e attori» accetta un input definito e restituisce «sistema autorizzato a cambiare lo stato» con provenienza. Il contratto gestisce «sovrascrivere stati più recenti» prima di invocare «propagare eventi con identificatori».
- 3
Propagare eventi con identificatori
Il passaggio «propagare eventi con identificatori» accetta un input definito e restituisce «stati locali e stato condiviso» con provenienza. Il contratto gestisce «perdere la motivazione della transizione» prima di invocare «rifiutare transizioni impossibili».
- 4
Rifiutare transizioni impossibili
Il passaggio «rifiutare transizioni impossibili» accetta un input definito e restituisce «gestione di annullamenti e riaperture» con provenienza. Il contratto gestisce «nessun owner per le anomalie» prima di invocare «riconciliare divergenze visibili».
- 5
Riconciliare divergenze visibili
Il passaggio «riconciliare divergenze visibili» accetta un input definito e restituisce «evento che crea la transizione» con provenienza. Il contratto gestisce «sincronizzare etichette omonime» prima di invocare «costruire una macchina a stati comune».
Due componenti, un contratto esplicito
Caso isolato: «evento che crea la transizione». Operazione osservata: «riconciliare divergenze visibili». Deviazione forzata: «sovrascrivere stati più recenti».
Contratto osservato: «State machine, event contract, correlation ID e reconciliation view». Il componente non può reinterpretare «evento che crea la transizione». Perimetro della prova: «assegnare ownership a stati e transizioni, non solo ai record».
Controprova: «stati locali e stato condiviso». Arresto: «nessun owner per le anomalie». Passo ammesso dopo il recupero: «mappare transizioni e attori». Verbale finale: «Come evitare che tre sistemi mostrino tre versioni diverse dello stesso caso?»
Differenza decisiva: «Usa una singola richiesta per distinguere stato locale, stato composto e vista per l’operatore». Regola di chiusura: «La vista unificata deve comporre eventi con origine e tempo, non sovrascrivere tre significati in un campo condiviso».
Il contratto fra i passaggi
Per trasferire «stati locali e stato condiviso» servono versione, provenienza e risultato ammesso. Se «propagare eventi con identificatori» deve reinterpretare uno di questi elementi, la separazione fra componenti è soltanto grafica.
Nel tema «assegnare ownership a stati e transizioni, non solo ai record» un output limitato e validabile è più sicuro di una risposta ricca davanti a «sovrascrivere stati più recenti». Gli stati «non disponibile» e «richiede revisione» fanno parte del contratto; il controesempio viene cercato in «costruire una macchina a stati comune».
Dove l’architettura deve fermarsi
«sincronizzare etichette omonime» può consentire un nuovo tentativo; «sovrascrivere stati più recenti» può richiedere autorizzazione; «perdere la motivazione della transizione» può invalidare la fonte. Un solo fallback nasconderebbe decisioni diverse.
Sincronizzare etichette omonime
Rischio nominato: «sincronizzare etichette omonime». Perimetro operativo: «assegnare ownership a stati e transizioni, non solo ai record». Segnale osservato: «sistema autorizzato a cambiare lo stato». Recupero ammesso: «riconciliare divergenze visibili». Checkpoint finale: «sistema autorizzato a cambiare lo stato».
Sovrascrivere stati più recenti
Rischio nominato: «sovrascrivere stati più recenti». Perimetro operativo: «assegnare ownership a stati e transizioni, non solo ai record». Segnale osservato: «stati locali e stato condiviso». Recupero ammesso: «costruire una macchina a stati comune». Checkpoint finale: «stati locali e stato condiviso».
Perdere la motivazione della transizione
Rischio nominato: «perdere la motivazione della transizione». Perimetro operativo: «assegnare ownership a stati e transizioni, non solo ai record». Segnale osservato: «gestione di annullamenti e riaperture». Recupero ammesso: «mappare transizioni e attori». Checkpoint finale: «gestione di annullamenti e riaperture».
Nessun owner per le anomalie
Rischio nominato: «nessun owner per le anomalie». Perimetro operativo: «assegnare ownership a stati e transizioni, non solo ai record». Segnale osservato: «evento che crea la transizione». Recupero ammesso: «propagare eventi con identificatori». Checkpoint finale: «evento che crea la transizione».
Osservare il sistema con domande operative
La vista operativa collega «gestione di annullamenti e riaperture» al componente che ha deciso e al destinatario di «nessun owner per le anomalie». Un generico «success/fail» non risponde a nessuna di queste domande; la decisione resta collegata a «nessun owner per le anomalie».
L’operatore vede l’identificatore necessario a «riconciliare divergenze visibili»; i dettagli tecnici possono restare altrove, purché il collegamento non dipenda da nomi file o memoria individuale.
La decisione architetturale
La vista unificata deve comporre eventi con origine e tempo, non sovrascrivere tre significati in un campo condiviso. Il test di «State machine, event contract, correlation ID e reconciliation view» deve mantenere il confine durante errore, modifica e revoca.
La vista unificata deve comporre eventi con origine e tempo, non sovrascrivere tre significati in un campo condiviso. Il contratto è sufficiente quando «perdere la motivazione della transizione» resta confinato, «sistema autorizzato a cambiare lo stato» conserva provenienza e «rifiutare transizioni impossibili» non deve indovinare lo stato precedente.
Contesto e limiti
Questo scenario ipotetico evita benchmark inventati e osserva nel processo reale il tema «assegnare ownership a stati e transizioni, non solo ai record». Ogni estensione del perimetro richiede una nuova verifica.
Prossimo passo
Hai attività ripetitive fra email, fogli e gestionali?
L’Audit Digitale aiuta a capire dove i passaggi restano manuali e se ha senso approfondire un’automazione.