Leggere uno stato e creare un ordine sono problemi diversi
Immaginiamo una richiesta concreta: un portale clienti deve mostrare lo stato degli ordini e permettere di inviarne uno nuovo. Sembrano due schermate dello stesso progetto, ma hanno rischi diversi. Mostrare uno stato richiede di trovare il dato giusto, aggiornarlo con la frequenza necessaria e rispettare i permessi. Creare un ordine può attivare controlli su listini, disponibilità, plafond, numerazione, notifiche e contabilità. Scrivere una riga in una tabella potrebbe non eseguire nulla di tutto questo.
Descrivete il flusso senza nominare ancora la tecnologia: «Quando il cliente conferma un carrello, il gestionale deve ricevere una richiesta; se la accetta, il portale mostra il numero d'ordine; se la rifiuta, l'utente vede il motivo». Poi precisate chi decide se l'operazione è valida, quale sistema possiede il dato e quanto rapidamente deve aggiornarsi l'altro.
Le domande che definiscono il contratto
Le risposte fanno emergere il contratto da costruire. Un portale potrebbe avere bisogno soltanto di «statoOrdine» e «creaOrdine», non di conoscere tutte le tabelle del database. Rendere pubblico l'intero modello dati del gestionale solo perché è più rapido sarebbe un vincolo difficile da togliere dopo.
- Qual è il sistema che decide se l'operazione è valida?
- Quale dato appartiene al gestionale e quale al sistema terzo?
- L'aggiornamento deve essere immediato o può arrivare a intervalli?
- Che cosa succede se uno dei due sistemi è momentaneamente indisponibile?
- Come riconosciamo una richiesta già inviata, per evitare doppioni?
- Chi è autorizzato a leggere o modificare le informazioni?
Dove cercare il punto d'accesso
L'inventario parte dal software reale, non da un'architettura ideale. In molti prodotti sono già presenti canali utili. La lista seguente serve a indagare, non a promettere che ogni opzione sia disponibile. Una base dati può essere accessibile ma non spiegare le trasformazioni eseguite dal programma. Un export può contenere tutte le informazioni ma arrivare troppo tardi per il flusso richiesto.
- Funzioni del core: se la logica è invocabile da un servizio o da un componente isolabile, è spesso il punto più interessante per le operazioni che modificano dati.
- Importazioni ed esportazioni: file, code o processi batch possono essere adatti a sincronizzazioni non immediate, purché formati, errori e riesecuzione siano governati.
- Database: una vista o un accesso in sola lettura possono alimentare consultazioni specifiche. Le scritture richiedono un'analisi molto più severa delle regole applicative.
- Eventi e log applicativi: se il prodotto li emette in modo affidabile, possono segnalare cambiamenti senza interrogazioni continue.
- Automazione dell'interfaccia: in alcuni contesti è un ponte temporaneo quando non c'è altro punto disponibile; va valutata per fragilità, carico e capacità di diagnosticare errori.
Perché il collegamento diretto al database merita cautela
Un accesso diretto alle tabelle può funzionare per un report circoscritto e controllato. Diventa delicato quando il sistema terzo inizia a scrivere. Potrebbe saltare validazioni, aggiornare solo metà di una transazione o produrre uno stato che l'applicazione non sa gestire. Inoltre, il nuovo sistema finirebbe per dipendere dai nomi delle tabelle e dalle loro modifiche future. Martin Fowler descrive questo accoppiamento nelle integrazioni basate su un database condiviso.
Quando il database è l'unico accesso praticabile, si può valutare un componente che esponga poche operazioni controllate invece dello schema intero. La guida AWS sulla decomposizione di database presenta questa possibilità insieme ai suoi compromessi. Un wrapper non inventa le regole mancanti: bisogna comunque ricostruirle e provarle.
Fonti: Martin Fowler — Integration Database · AWS — Controllare l'accesso al database durante la decomposizione
Il Web Bridge come contratto tra due mondi
Per MadeInCode, Web Bridge significa costruire il collegamento necessario al caso d'uso. Può essere un adattatore piccolo, un gateway con più funzioni o una combinazione di processi esistenti. Non richiede per principio di sostituire il core né di introdurre una piattaforma complessa.
Il percorso è: portale, CRM o e-commerce → contratto del flusso e autorizzazione → adattatore o gateway → punto d'accesso verificato → gestionale esistente. L'adattatore traduce il linguaggio del sistema terzo in quello del prodotto: per esempio «invia ordine» può diventare una chiamata alla funzione interna che già applica listini e verifiche. Il pattern anti-corruption layer documentato da AWS descrive il ruolo di mediazione tra modelli diversi. Non impone uno specifico cloud o un'infrastruttura aggiuntiva: il componente va dimensionato sul problema.
Il contratto deve dichiarare almeno gli input ammessi, i permessi, le risposte, il comportamento in caso di errore e la gestione dei tentativi ripetuti. Servono anche log leggibili: se un ordine risulta «inviato» sul portale ma non compare nel gestionale, il team deve poter ricostruire quale passaggio si è fermato. Nei flussi che modificano dati, va deciso prima chi può riprovare e come evitare la creazione di due ordini identici.
Un primo flusso, dall'inizio alla fine
Torniamo all'esempio illustrativo. Potremmo iniziare dalla consultazione dello stato di un ordine per un solo gruppo di utenti, definendo quali stati mostrare e con quale ritardo massimo. La prova comprende permessi, ordini inesistenti, aggiornamenti e indisponibilità temporanea del gestionale. Se la consultazione funziona, affrontiamo la creazione dell'ordine usando, se possibile, la stessa operazione che l'applicazione attuale usa per validarlo.
Il risultato da verificare non è soltanto che il portale riceva una risposta positiva. È che l'ordine appaia nel gestionale con importi e stato corretti, gli errori siano comprensibili, un invio duplicato non crei effetti inattesi e il supporto riesca a capire che cosa è successo. Solo allora ha senso estendere il collegamento ad altri clienti o funzioni.
Se hai un gestionale senza API e una richiesta d'integrazione concreta, descrivici il flusso. Nel Legacy Assessment individuiamo accessi, vincoli e rischi; con il Web Bridge realizziamo e verifichiamo il primo collegamento utile.