Scenari di indirizzo transfrontaliero: quanti paesi ci sono in un ordine

Gli scenari di indirizzo transfrontaliero vengono spesso testati come se un unico valore di paese attraversasse la transazione. In pratica un ordine ne porta spesso più di uno: dove il cliente è registrato, dove va la fattura, dove viene consegnato il pacco e sotto le regole di identità di quale paese il cliente è stato verificato.

Ciascuno di questi è un paese legittimo, e non sono tenuti a coincidere. Il lavoro interessante consiste nel decidere cosa debba concordare, cosa possa differire e quale dei valori sia autorizzato a governare una regola di convalida.

Quanti valori di paese può portare un solo ordine?

Quattro è un conteggio di partenza utile, e sono abbastanza distinti che unire due qualsiasi di essi fa perdere informazioni.

Un quinto appare ogni volta che una piattaforma, un venditore di marketplace e un corriere hanno ciascuno la propria visione della destinazione. Non è un caso limite; è la forma normale di una transazione transfrontaliera con più di un partecipante.

La prima decisione di modellazione è se questi vengano memorizzati come un unico indirizzo con diverse etichette o come diversi indirizzi legati tra loro per caso. Entrambi possono funzionare, ma un sistema che memorizza un solo paese e lo riscrive a ogni passaggio non può in seguito rispondere alla domanda che porrà una contestazione: quale paese era vero nel momento in cui è stato effettuato l’ordine?

Quale di essi dovrebbe governare la convalida?

Non esiste una risposta universale, ed è proprio per questo che la regola deve essere messa per iscritto. Esistono diverse politiche difendibili, e mescolarle silenziosamente è ciò che produce il difetto in cui un valore è accettato in una schermata e rifiutato in quella successiva.

Una politica è che governi il paese di consegna, perché l’indirizzo che deve essere fisicamente raggiungibile è quello le cui convenzioni contano di più. Un’altra è che governi il paese di fatturazione, perché gli strumenti di pagamento e le loro regole di solito seguono il pagatore. Una terza è che ogni campo sia convalidato contro il paese a cui appartiene, che è la più corretta e la più impegnativa da implementare.

Qualunque sia la scelta, la modalità di guasto del non scegliere è coerente: due componenti non sono d’accordo, all’utente viene detto che il suo indirizzo non è valido, e nulla nel messaggio dice a quale dei quattro valori di paese si riferisca la lamentela.

Cosa succede quando i campi non concordano tra loro?

Il disaccordo è normalmente un segnale più che un errore. Un indirizzo di consegna in un paese e un numero di telefono il cui prefisso appartiene a un altro non è degno di nota per chi vive vicino a un confine, ed è anche un pattern noto nelle frodi, quindi trattarlo come automaticamente non valido fa perdere clienti legittimi.

L’approccio pratico è distinguere le condizioni bloccanti da quelle consultive. Pochissimi disaccordi impediscono davvero di procedere con l’ordine; la maggior parte riduce semplicemente la fiducia, e la fiducia è meglio gestita come segnale raccolto per la revisione che come errore di convalida mostrato al cliente.

La suite di test dovrebbe quindi contenere disallineamenti deliberati. Un paese di consegna diverso dal paese di fatturazione, un prefisso telefonico che appartiene a un terzo paese e una valuta la cui sede abituale è un quarto sono tre casi che una fixture a un solo paese non può mai produrre, e sono i casi in cui si concentrano i difetti transfrontalieri.

Esiste già una guida dedicata a uno di questi segnali, sulla corrispondenza tra prefisso telefonico e località, che copre in dettaglio il lato del prefisso; qui è sufficiente notare che il segnale appartiene a un paese diverso dall’indirizzo che accompagna.

Chi possiede la decisione quando un valore viene rifiutato?

La proprietà è la parte che viene saltata, e la sua assenza è ciò che trasforma un bug transfrontaliero in una lunga discussione.

Per ogni regola di convalida, qualcuno dovrebbe essere in grado di rispondere a tre domande. Quale valore di paese ha selezionato questa regola? Qual è la giustificazione della regola? E chi può cambiarla? Una regola il cui proprietario è sconosciuto non può essere modificata in sicurezza, quindi resta al suo posto e accumula eccezioni ai margini.

Assegnare la proprietà espone anche le regole che esistono senza motivo. Una regola ereditata che rifiuta un valore ben formato per un paese con cui nessuno commercia è puro costo, e non emergerà mai finché non si chiederà a qualcuno di difenderla.

Per gli sviluppatori: modellare i ruoli, non un solo campo paese

Dai a ogni ruolo il proprio valore, con il proprio ciclo di vita e la propria convalida, e lascia che la transazione registri quale ruolo ha governato quale decisione. Quell’unico cambiamento trasforma la maggior parte delle domande transfrontaliere da archeologia in una ricerca.

Poi testa le combinazioni invece dei campi. Una matrice in cui il paese di consegna, il paese di fatturazione e il prefisso telefonico variano in modo indipendente è abbastanza piccola da essere eseguita e abbastanza grande da catturare i disaccordi che contano. Dove è coinvolto un piccolo territorio, le insidie specifiche sono coperte nella guida a piccoli territori e codici speciali, perché quelle destinazioni sono il luogo in cui i disallineamenti di ruolo vengono gestiti male più spesso.

Mantieni leggibili i casi risultanti. Un caso denominato per ciò che varia vale più di un caso denominato per il ticket che lo ha prodotto. Per la forma dell’indirizzo stesso una volta stabilito il paese, la directory dei paesi e delle regioni e una pagina come la voce della Germania mostrano come sono descritte in isolamento le convenzioni di un paese, che è il punto di confronto corretto prima di aggiungere un secondo paese alla transazione.

Tutti gli indirizzi, le combinazioni di paesi e i dettagli dell’ordine usati in questo articolo sono esempi fittizi scritti per illustrare una questione di modellazione. Non descrivono alcun cliente, ordine o transazione reale, e nessun valore mostrato qui dovrebbe essere letto come dati provenienti da un sistema in produzione.

Passi successivi

Prendi un record d’ordine esistente e prova a rispondere, dai soli dati memorizzati, quale paese abbia governato ciascuna convalida eseguita al checkout. Se qualcuna di quelle risposte non è disponibile, i ruoli non sono ancora modellati separatamente. La guida a paese e lingua copre la distinzione vicina tra il luogo e la lingua, che i casi transfrontalieri tendono a confondere allo stesso modo.