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

Percakapan 1 – Minimal Abstraction of the Domain

User 😊 : Deci, când schimbăm punctul de vămuire, trebuie să refacem întregul plan de rutare.

Developer 🤓 : Corect. Vom șterge toate rândurile din tabelul de expediere cu acel id al încărcăturii, apoi vom trece originea, destinația și noul punct de vămuire în serviciul de rutare, iar acesta va repopula tabelul. Va trebui să avem un boolean în Cargo, astfel încât să știm că există date în tabelul de expediere.

😊 : Să ștergem rândurile? OK, mă rog. Oricum, dacă înainte nu aveam deloc un punct de vămuire, va trebui să facem același lucru.

🤓 : Sigur, de fiecare dată când schimbați originea, destinația sau punctul de vămuire (sau introduceți unul pentru prima dată), vom verifica dacă avem date despre expediere și apoi le vom șterge și apoi vom lăsa Serviciul de rutare să le regenereze.

😊 : Desigur, dacă vechiul punct de vămuire s-a întâmplat să fie cel corect, nu am vrea să facem asta.

🤓 : Oh, nicio problemă. Este mai ușor să punem serviciul de rutare să refacă de fiecare dată încărcăturile și descărcările.

😊 : Da, dar este o muncă în plus pentru noi să facem toate planurile de sprijin pentru un nou itinerar, așa că nu vrem să refacem rutele decât dacă cange-ul o impune.

🤓 : Ugh. Ei bine, atunci, dacă intrați pentru prima dată într-un punct de vămuire, va trebui să interogăm tabelul pentru a găsi vechiul punct de vămuire derivat și apoi să îl comparăm cu cel nou. Apoi vom ști dacă trebuie să-l refacem.

😊 : Nu va trebui să vă faceți griji cu privire la acest lucru la origine sau la destinație, deoarece itinerariul s-ar schimba întotdeauna atunci.

🤓 : Bine. Nu vom face asta.

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

😊 : Deci, atunci când schimbăm punctul de vămuire, trebuie să refacem întregul plan de rutare.

🤓 : Corect. Când schimbați oricare dintre atributele din specificația de rută, vom șterge vechiul itinerar și vom cere serviciului de rutare să genereze unul nou pe baza noii specificații de rută.

😊 : Dacă nu am specificat deloc un punct de vămuire înainte, va trebui să facem acest lucru în același timp.

🤓 : Sigur, de fiecare dată când schimbați ceva din specificația de rută, vom regenera itinerariul. Asta include și introducerea a ceva pentru prima dată.

😊 : Desigur, dacă vechea vămuire s-a întâmplat să fie cea corectă, nu am vrea să facem asta.

🤓 : Oh, nicio problemă. Este mai simplu să facem serviciul de rutare să refacă itinerariul de fiecare dată.

😊 : Da, dar este o muncă suplimentară pentru noi să facem toate planurile de sprijin pentru un nou itinerar, așa că nu vrem să refacem traseul decât dacă schimbarea o impune.

🤓 : Oh. Atunci va trebui să adăugăm o funcționalitate la specificația traseului. Apoi, ori de câte ori se va schimba ceva în Specificație, vom vedea dacă Itinerariul încă mai satisface Specificația. Dacă nu, vom pune serviciul de rutare să regenereze itinerariul.

😊 : Nu va trebui să vă faceți griji în legătură cu acest lucru la origine sau la destinație, deoarece itinerariul se va schimba întotdeauna atunci.

🤓 : Bine, dar va fi mai simplu pentru noi să facem doar comparația de fiecare dată. Itinerarul va fi generat doar atunci când specificația rutei nu mai este satisfăcută.

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).

Experții de domeniu (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 minim 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 (jargon/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).

Diagrama venn dibawah adalah ilustrasi untuk menggambarkan ubiquitous language.