Il punto di partenza.

Il lavoro archivistico era governato da un processo, ma agli operatori serviva comunque un modo pratico per gestire ciò che vi passava: sessioni, pacchetti e stato del workflow.

La funzionalità doveva vivere dentro una piattaforma enterprise più ampia. Non poteva diventare un prodotto separato con regole proprie. Serviva un confine mirato che rispettasse il sistema circostante.

Cosa doveva risolvere il design.

Il confine utile si trovava tra stato del processo e azione dell’operatore:

  1. Una sessione e i suoi pacchetti dovevano restare comprensibili durante l’avanzamento.
  2. Le azioni dell’operatore dovevano corrispondere a transizioni valide.
  3. Regole backend e stato frontend non potevano divergere in interpretazioni diverse.
  4. La funzionalità doveva integrarsi senza disperdere la propria logica nella piattaforma host.

La diagnosi.

Camunda poteva coordinare il processo, ma l’orchestrazione da sola non costituiva l’esperienza operativa. Mancava un confine applicativo coerente attorno al workflow.

Ho separato le responsabilità: il servizio Spring gestisce le regole applicative e l’integrazione di processo; il microfrontend React presenta lo stato corrente e le azioni valide.

La sezione applicativa risultante.

Il microfrontend offre agli operatori una superficie mirata. Il servizio Spring traduce le azioni in operazioni di workflow, mentre Camunda coordina il processo che fa avanzare sessioni e pacchetti.

La sezione applicativa risultante. Un confine chiaro tra azione utente, regole applicative e stato del processo.SYSTEM VIEW / WORKFLOWOPERATOREUI REACTSERVIZIO SPRINGCAMUNDASESSIONI +PACCHETTIPROCESS STATE RETURNS TO THE OPERATOR VIEW
Un confine chiaro tra azione utente, regole applicative e stato del processo.

Le decisioni importanti.

Il design resta utile perché ogni responsabilità ha un posto preciso.

D01

Mettere il workflow dietro un servizio

Il client React parla con una API Spring mirata, invece di codificare nel browser i meccanismi del processo.

Il servizio aggiunge un confine da mantenere, ma impedisce ai dettagli del workflow di invadere ogni schermata.

D02

Mostrare lo stato prima dell’azione

L’interfaccia mette al centro la sessione corrente, i pacchetti e lo stato del processo, così l’operatore capisce cosa succede prima di agire.

La UI deve rappresentare anche stati indisponibili e in corso, non solo il percorso ideale.

D03

Mantenere stretto il perimetro

Il microfrontend contiene l’esperienza archivistica e allo stesso tempo si inserisce nella piattaforma enterprise.

Questa indipendenza dipende da un contratto d’integrazione disciplinato con l’applicazione host.

Delivery e verifica.

La funzionalità si verifica lungo lo stesso percorso dell’operatore: creare o aprire una sessione, controllare i pacchetti, eseguire un’azione ammessa e confermare che lo stato torni coerente nell’interfaccia.

I casi critici sono ai confini. Il servizio deve rifiutare transizioni non valide, la UI deve mostrare con onestà stati incompleti o in attesa e l’integrazione deve mantenere il processo come fonte dello stato.

Il risultato qualitativo.

La sezione risultante copre gestione delle sessioni, elaborazione dei pacchetti e controllo del workflow, dall’interfaccia dell’operatore fino al processo Camunda.

Gli operatori hanno un solo luogo in cui capire il lavoro e farlo avanzare. La piattaforma più ampia riceve una funzionalità contenuta, non logica archivistica dispersa tra schermate e servizi.