Perhatikan diagram dan percakapan berikut. Percakapan ini terjadi antara business person (user) dengan developer tentang sebuah sistem informasi kargo.

Percakapan 1 – Minimal abstraktion av domänen

User 😊 : Så när vi ändrar tullklareringspunkten måste vi göra om hela ruttplaneringen.

Developer 🤓 : Just det. Vi raderar alla rader i tabellen för försändelser med detta frakt-id, sedan skickar vi in ursprunget, destinationen och den nya tullklareringspunkten till routingtjänsten, så fyller den tabellen på nytt. Vi måste ha ett boolean i Cargo så att vi vet att det finns data i tabellen Shipment.

😊 : Radera raderna? Okej, vad som helst. Hur som helst, om vi inte hade någon tullklareringspunkt alls tidigare måste vi göra samma sak.

🤓 : Visst, varje gång du ändrar ursprung, destination eller tullklareringspunkt (eller anger en sådan för första gången) kontrollerar vi om vi har uppgifter om försändelsen och sedan raderar vi dem och låter sedan Routing Service återskapa dem.

😊 : Om den gamla förtullningen råkade vara den rätta skulle vi naturligtvis inte vilja göra det.

🤓 : Inga problem. Det är lättare att låta Routing Service göra om lastningarna och lossningarna varje gång.

😊 : Ja, men det är extra arbete för oss att göra alla stödplaner för en ny resväg, så vi vill inte göra om routningen om inte kange kräver det.

🤓 : Usch. Nåväl, om du går in i en tullklareringspunkt för första gången måste vi fråga i tabellen för att hitta den gamla härledda tullklareringspunkten och sedan jämföra den med den nya. Då vet vi om vi måste göra om det.

😊 : Du behöver inte oroa dig för detta när det gäller ursprung eller destination, eftersom resvägen alltid ändras då.

🤓 : Bra. Det ska vi inte.

Sekarang perhatikan diagram dan percakapan berikut. Ini adalah percakapan yang sama persis, tetapi menggunakan bahasa (kosakata) yang berbeda.

Percakapan 2 – Domain Model Enriched to Support Discussion

😊 : Så när vi ändrar förtullningspunkten måste vi göra om hela ruttplanen.

🤓 : Just det. När du ändrar något av attributen i ruttspecifikationen raderar vi den gamla resplanen och ber routingtjänsten att generera en ny utifrån den nya ruttspecifikationen.

😊 : Om vi inte hade angett någon tullklareringspunkt alls tidigare måste vi göra det samtidigt.

🤓 : Visst, när du ändrar något i ruttspecifikationen genererar vi resplanen på nytt. Det gäller även om du anger något för första gången.

😊 : Naturligtvis, om den gamla förtullningen bara råkade vara den rätta skulle vi inte vilja göra det.

🤓 : Åh, inga problem. Det är lättare att låta routingtjänsten göra om resplanen varje gång.

😊 : Ja, men det är extra arbete för oss att göra alla stödplaner för en ny resplan, så vi vill inte göra en ny rutt om det inte är nödvändigt på grund av ändringen.

🤓 : Åh, då måste vi lägga till en viss funktionalitet i ruttspecifikationen. När du sedan ändrar något i specifikationen kan vi se om färdplanen fortfarande uppfyller specifikationen. Om den inte gör det, får vi rutintjänsten att återskapa resplanen.

😊 : Du behöver inte oroa dig för detta när det gäller ursprung eller destination, eftersom resplanen alltid ändras då.

🤓 : Visst, men det blir enklare för oss att bara göra jämförelsen varje gång. Resplanen kommer endast att genereras när ruttspecifikationen inte längre uppfylls.

Gambar dibawah ini mengilustrasikan domain experts dan software developers yang sedang berdiskusi. Gambar sebelah kiri adalah software developers (digambarkan dengan pikiran yang penuh dengan teknologi), sedangkan gambar sebelah kanan adalah domain experts (digambarkan dengan pikiran yang penuh dengan uang, atau bisa diartikan sebagai bisnis).

Domänexperter (dalam percakapan di atas adalah business person/user) memiliki pengetahuan yang terbatas mengenai jargon yang digunakan dalam software development, tetapi mereka memiliki jargon sendiri sesuai dengan disiplin ilmu yang mereka punyai.

Sementara itu, developers sangat fasih menggunakan istilah-istilah di dalam software development, tetapi mungkin memiliki pengetahuan yang minim mengenai jargon yang digunakan oleh domain experts (misalnya, dalam kasus percakapan di atas, developer memiliki pengetahuan yang miniman akan dunia kargo).

Dalam situasi ini, ubiquitous language difungsikan, dengan tujuan, domain experts dan developers bisa saling mengerti apa yang sedang didiskusikan karena mereka menggunakan istilah (jargong/kosakata) yang sama. Istilah tersebut merujuk pada hal yang sama persis, misalnya, kosakata Route Specification selalu merujuk pada hal yang terdiri dari origin, destination dan custom clearance point (lihat diagram).

Diagram venn dibawah adalah ilustrasi untuk menggambarkan ubiquitous language.