Grensoverschrijdende adresscenario’s worden vaak getest alsof er één enkele landwaarde door de transactie reist. In de praktijk draagt een order er dikwijls meer dan één: waar de klant is geregistreerd, waar de factuur naartoe gaat, waar het pakket wordt bezorgd, en onder welk land de identiteit van de klant is geverifieerd.
Elk daarvan is een legitiem land, en ze hoeven niet overeen te komen. Het interessante werk is beslissen wat moet overeenkomen, wat mag verschillen, en welke van de waarden een validatieregel mag sturen.
Hoeveel landwaarden kan één order dragen?
Vier is een nuttig beginaantal, en ze zijn zo verschillend dat het samenvoegen van twee ervan informatie kost.
| Rol | Wat hij beschrijft | Verandert wanneer |
|---|---|---|
| Registratieland | Waar het account is aangemaakt | Bijna nooit |
| Factuurland | Welke regels en valuta de betaling volgt | Bij een wijziging van betaalmethode |
| Bezorgland | Waar de goederen naartoe gaan | Bij elke order |
| Identiteitsland | Met welk document de persoon is geverifieerd | Wanneer het document wordt vernieuwd of vervangen |
Een vijfde verschijnt telkens wanneer een platform, een marktplaatsverkoper en een koerier elk hun eigen kijk op de bestemming hebben. Dat is geen randgeval; het is de normale vorm van een grensoverschrijdende transactie met meer dan één deelnemer.
De eerste modelleerbeslissing is of deze als één adres met meerdere labels worden opgeslagen of als meerdere adressen die toevallig verwant zijn. Beide kunnen werken, maar een systeem dat één land opslaat en het bij elke stap herschrijft, kan daarna niet de vraag beantwoorden die een geschil zal stellen: welk land was waar op het moment dat de order werd geplaatst?
Welke van hen moet de validatie sturen?
Er is geen universeel antwoord, en juist daarom moet de regel worden opgeschreven. Er bestaan meerdere verdedigbare beleidslijnen, en ze stilzwijgend vermengen is wat het defect oplevert waarbij een waarde op het ene scherm wordt geaccepteerd en op het volgende wordt afgewezen.
Eén beleidslijn is dat het bezorgland stuurt, omdat het adres dat fysiek bereikbaar moet zijn degene is wiens conventies het meest ertoe doen. Een andere is dat het factuurland stuurt, omdat betaalinstrumenten en hun regels meestal de betaler volgen. Een derde is dat elk veld tegen het land wordt gevalideerd waartoe het behoort, wat het meest correct is en het meest veeleisend om te implementeren.
Wat er ook wordt gekozen, de faalwijze van niet-kiezen is consistent: twee componenten zijn het oneens, de gebruiker krijgt te horen dat zijn adres ongeldig is, en niets in de melding zegt op welk van de vier landwaarden de klacht betrekking heeft.
Wat gebeurt er wanneer de velden het onderling oneens zijn?
Onenigheid is normaal een signaal en geen fout. Een bezorgadres in het ene land en een telefoonnummer waarvan de prefix bij een ander hoort, is niets bijzonders voor iemand die nabij een grens woont, en het is ook een bekend patroon in fraude, dus het automatisch als ongeldig behandelen kost legitieme klanten.
De praktische aanpak is blokkerende voorwaarden van adviserende te onderscheiden. Zeer weinig meningsverschillen verhinderen werkelijk dat de order doorgaat; de meeste verlagen simpelweg het vertrouwen, en vertrouwen kun je beter behandelen als een signaal dat voor beoordeling wordt verzameld dan als een validatiefout die aan de klant wordt getoond.
De testsuite hoort daarom opzettelijke mismatches te bevatten. Een bezorgland dat afwijkt van het factuurland, een telefoonprefix die bij een derde land hoort, en een valuta waarvan het gebruikelijke thuisland een vierde is, zijn drie gevallen die een fixture met één land nooit kan produceren, en het zijn de gevallen waar grensoverschrijdende defecten zich concentreren.
Er is al een aparte gids over een van deze signalen, namelijk over telefoonprefix en plaatsmatching, die de prefixkant in detail behandelt; hier is het genoeg om op te merken dat het signaal tot een ander land behoort dan het adres dat het vergezelt.
Wie is eigenaar van de beslissing wanneer een waarde wordt afgewezen?
Eigenaarschap is het deel dat wordt overgeslagen, en het ontbreken ervan is wat een grensoverschrijdende bug in een lange discussie verandert.
Voor elke validatieregel zou iemand drie vragen moeten kunnen beantwoorden. Welke landwaarde heeft deze regel geselecteerd? Wat is de rechtvaardiging van de regel? En wie kan hem wijzigen? Een regel waarvan de eigenaar onbekend is, kan niet veilig worden aangepast, dus blijft hij staan en verzamelt hij uitzonderingen aan de randen.
Het toewijzen van eigenaarschap legt ook regels bloot die zonder reden bestaan. Een geërfde regel die een goed gevormde waarde afwijst voor een land waarmee niemand handelt, is pure kostenpost, en hij komt nooit aan het licht tot iemand wordt gevraagd hem te verdedigen.
Voor ontwikkelaars: modelleer de rollen, niet één landveld
Geef elke rol zijn eigen waarde, met zijn eigen levenscyclus en zijn eigen validatie, en laat de transactie vastleggen welke rol welke beslissing stuurde. Die ene verandering maakt van de meeste grensoverschrijdende vragen archeologie in plaats van een opzoeking.
Test dan de combinaties in plaats van de velden. Een matrix waarin het bezorgland, het factuurland en de telefoonprefix onafhankelijk worden gevarieerd, is klein genoeg om te draaien en groot genoeg om de meningsverschillen te vangen die ertoe doen. Waar een klein gebied in het spel is, worden de specifieke valkuilen behandeld in de gids over kleine gebieden en speciale codes, want die bestemmingen zijn waar rolverschillen het vaakst verkeerd worden afgehandeld.
Houd de resulterende gevallen leesbaar. Een geval dat is genoemd naar wat het varieert, is meer waard dan een geval dat is genoemd naar de ticket die het opleverde. Voor de vorm van het adres zelf zodra het land vaststaat, tonen de landen- en regiorgids en een pagina zoals de vermelding voor Duitsland hoe de conventies van één land geïsoleerd worden beschreven, wat het juiste vergelijkingspunt is voordat je een tweede land aan de transactie toevoegt.
Alle adressen, landcombinaties en orderdetails in dit artikel zijn fictieve voorbeelden die zijn geschreven om een modelleervraag te illustreren. Ze beschrijven geen echte klant, order of transactie, en geen enkele hier getoonde waarde mag worden gelezen als gegevens uit een live systeem.
Volgende stappen
Neem één bestaand orderrecord en probeer uit de opgeslagen gegevens alleen te beantwoorden welk land elke validatie stuurde die tijdens het afrekenen liep. Als een van die antwoorden niet beschikbaar is, zijn de rollen nog niet afzonderlijk gemodelleerd. De gids over land versus taal behandelt het naburige onderscheid tussen de plek en de taal, dat grensoverschrijdende gevallen op dezelfde manier geneigd zijn te verwarren.