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 😊 : Tehát amikor megváltoztatjuk a vámkezelési pontot, újra kell készítenünk az egész útvonaltervet.

Developer 🤓 : Right. Töröljük az összes sort a küldeménytáblában ezzel a rakományazonosítóval, majd átadjuk a származási helyet, a célállomást és az új vámkezelési pontot az útválasztási szolgáltatásnak, és az újra feltölti a táblát. Kell egy Boolean a Cargo-ban, hogy tudjuk, hogy van adat a szállítmány táblában.

😊 : Töröljük a sorokat? Oké, mindegy. Mindenesetre, ha korábban egyáltalán nem volt vámkezelési pontunk, akkor ugyanezt kell tennünk.

🤓 : Persze, bármikor, amikor megváltoztatjuk a származási, rendeltetési vagy vámkezelési pontot (vagy először adunk meg egyet), ellenőrizzük, hogy vannak-e küldeményadatok, majd töröljük őket, és hagyjuk, hogy az útválasztó szolgáltatás újragenerálja őket.

😊 : Persze, ha a régi vámkezelési pont véletlenül éppen a megfelelő, akkor ezt nem szeretnénk megtenni.

🤓 : Ó, nem probléma. Egyszerűbb, ha az Útválasztó Szolgálatot rávesszük, hogy minden alkalommal végezze el újra a be- és kirakodásokat.

😊 : Igen, de nekünk plusz munkát jelent, hogy minden támogató tervet elkészítsünk egy új útvonalhoz, ezért nem akarunk átirányítani, hacsak a cange nem teszi szükségessé.

🤓 : Fúj. Nos, akkor, ha először lépsz be egy vámkezelési pontra, akkor le kell kérdeznünk a táblázatot, hogy megtaláljuk a régi származtatott vámkezelési pontot, majd összehasonlítjuk az újjal. Akkor tudni fogjuk, hogy újra kell-e csinálni.

😊 : Emiatt nem kell aggódni a kiindulási vagy a célállomáson, mivel akkor mindig változik az útvonal.

🤓 : Jó. Nem fogunk.

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

😊 : Tehát amikor megváltoztatjuk a vámkezelési pontot, újra kell készítenünk az egész útvonaltervet.

🤓 : Így van. Amikor megváltoztatjuk az útvonalspecifikáció bármelyik attribútumát, töröljük a régi útvonaltervet, és megkérjük az útvonaltervező szolgáltatást, hogy generáljon egy újat az új útvonalspecifikáció alapján.

😊 : Ha korábban egyáltalán nem adtunk meg vámkezelési pontot, akkor azt is meg kell tennünk egyszerre.

🤓 : Persze, bármikor, amikor bármit megváltoztatunk az útvonalspecifikációban, újra generáljuk az útvonaltervet. Ebbe beletartozik az is, ha először adunk meg valamit.

😊 : Persze, ha a régi vámkezelés éppen véletlenül a megfelelő, akkor ezt nem szeretnénk megtenni.

🤓 : Ó, nem probléma. Egyszerűbb, ha az útvonaltervező szolgáltatással minden alkalommal újra elkészíttetjük az útvonalat.

😊 : Igen, de nekünk plusz munkát jelent az összes támogató terv elkészítése egy új útvonalhoz, ezért nem akarunk átirányítani, hacsak a változás nem teszi szükségessé.

🤓 : Ó. Akkor hozzá kell adnunk néhány funkciót az útvonalspecifikációhoz. Aztán, amikor bármit megváltoztatsz a specifikációban, megnézzük, hogy az Útvonal még mindig megfelel-e a specifikációnak. Ha nem, akkor az Útvonaltervező szolgáltatással újratermeltetjük az Útvonalat.

😊 : Nem kell aggódnod emiatt a kiindulási vagy a célállomáson, mivel az Útvonal akkor mindig változik.

🤓 : Jó, de egyszerűbb lesz számunkra, ha minden alkalommal elvégezzük az összehasonlítást. Az Itinerary csak akkor lesz generálva, ha az Route Specification már nem felel meg.

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

Domain experts (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).

Diagram venn dibawah adalah ilustrasi untuk menggambarkan ubiquitous language.