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

Percakapan 1 – Minimální abstrakce domény

User 😊 : Takže když změníme místo celního odbavení, musíme předělat celý plán trasování.

Developer 🤓 : Správně. Vymažeme všechny řádky v tabulce zásilek s tímto id nákladu, pak předáme původ, cíl a nový bod celního odbavení do služby Směrování a ta tabulku znovu naplní. Budeme muset mít v Cargo logickou hodnotu, abychom věděli, že v tabulce zásilek jsou data.

😊 : Smazat řádky? Dobře, to je jedno. Každopádně pokud jsme předtím vůbec neměli místo celního odbavení, budeme muset udělat totéž.

🤓 : Jistě, kdykoli změníme místo původu, určení nebo místo celního odbavení (nebo ho zadáme poprvé), zkontrolujeme, zda máme data o zásilce, a pak je odstraníme a necháme službu Směrování přegenerovat.

😊 : Samozřejmě, pokud by staré celní odbavení bylo náhodou to správné, nechtěli bychom to dělat.

🤓 : Aha, žádný problém. Je jednodušší prostě donutit směrovací službu, aby pokaždé znovu provedla nakládku a vykládku.

😊 : Ano, ale je to pro nás práce navíc, abychom vytvořili všechny podpůrné plány pro novou trasu, takže nechceme měnit trasu, pokud to cange nevyžaduje.

🤓 : Uff. Dobrá, pokud tedy poprvé vstupujete do místa celního odbavení, budeme se muset dotázat do tabulky, abychom našli staré odvozené místo celního odbavení, a pak ho porovnat s novým. Pak budeme vědět, jestli ho musíme předělat.“

😊 : Na místě původu ani na místě určení se o to nebudete muset starat, protože pak by se vždy změnil itinerář.“

🤓 : Dobře. Nebudeme.

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

Percakapan 2 – Model domény obohacený pro podporu diskuse

😊 : Takže když změníme místo celního odbavení, musíme celý plán směrování předělat.

🤓 : Správně. Když změníte některý z atributů ve specifikaci trasy, odstraníme starý itinerář a požádáme směrovací službu, aby vygenerovala nový na základě nové specifikace trasy.

😊 : Pokud jsme předtím vůbec nezadali místo celního odbavení, budeme to muset udělat současně.

🤓 : Jistě, kdykoli změníte cokoli ve specifikaci trasy, přegenerujeme itinerář. To se týká i toho, že něco zadáme poprvé.

😊 : Samozřejmě, pokud by staré odbavení bylo náhodou to správné, tak bychom to dělat nechtěli.

🤓 : Aha, žádný problém. Jednodušší je prostě nechat službu Směrování pokaždé předělat Itinerář.

😊 : Ano, ale je to pro nás práce navíc, abychom vytvořili všechny podpůrné plány pro nový Itinerář, takže nechceme měnit trasu, pokud to změna nevyžaduje.

🤓 : Aha. Pak budeme muset přidat nějakou funkci do Specifikace trasy. Pak, kdykoli ve Specifikaci něco změníte, zjistíme, zda Itinerář stále vyhovuje Specifikaci. Pokud ne, necháme službu Routing Service přegenerovat Itinerář.

😊 : O to se nebudete muset starat na počátku ani v cíli, protože Itinerář by se pak vždy změnil.

🤓 : Fajn, ale pro nás bude jednodušší prostě pokaždé provést porovnání. Itinerář se vygeneruje pouze tehdy, když specifikace trasy přestane vyhovovat.

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

Domainoví experti (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.

.