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

Percakapan 1 – Minimale abstractie van het domein

User 😊 : Dus als we het inklaringspunt veranderen, moeten we het hele routingplan opnieuw maken.

Developer 🤓 : Juist. We verwijderen alle rijen in de zendingtabel met die vracht-id, dan geven we de oorsprong, bestemming en het nieuwe inklaringspunt door aan de Routing Service, en die zal de tabel opnieuw vullen. We moeten een Boolean in de vracht hebben, zodat we weten dat er gegevens in de zendingstabel staan.

😊 : De rijen verwijderen? OK, wat dan ook. Anyway, if we didn’t have a customs clearance point at all before, we’ll have to do the same thing.

🤓 : Sure, whenever you change the origin, destination, or customs clearance point (or enter one for the first time), we’ll check to see if we have shipment data and then we’ll delete it and then let the Routing Service regenerate it.

😊 : Natuurlijk, als de oude douane-inklaring toevallig de juiste is, zouden we dat niet willen doen.

🤓 : Oh, geen probleem. Het is makkelijker om de Routing Service gewoon elke keer de ladingen en lossingen opnieuw te laten doen.

😊 : Ja, maar het is voor ons extra werk om alle ondersteunende plannen voor een nieuwe route te maken, dus we willen niet omleiden tenzij de cange het noodzakelijk maakt.

🤓 : Ugh. Welnu, als u voor de eerste keer een douane-afhandelingspunt binnengaat, moeten wij de tabel raadplegen om het oude afgeleide douane-afhandelingspunt te vinden, en het dan vergelijken met het nieuwe. Dan weten we of we het opnieuw moeten doen.

😊 : Je hoeft je hier geen zorgen over te maken bij vertrek of bestemming, omdat de route dan altijd verandert.

🤓 : Goed. Dat doen we niet.

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

😊 : Dus als we het inklaringspunt veranderen, moeten we het hele routingplan opnieuw maken.

🤓 : Juist. When you change any of the attributes in the Route Specification, we’ll delete the old Itinerary and ask the Routing Service to generate a new one based on the new Route Specification.

😊 : If we had’t specified a customs clearance point at all before, we’ll have to do that at the same time.

🤓 : Sure, anytime you change anything the Route Spec, we’ll regenerate the Itinerary. Dat is inclusief het voor de eerste keer invoeren van iets.

😊 : Natuurlijk, als de oude douane-inklaring toevallig de juiste was, zouden we dat niet willen doen.

🤓 : Oh, geen probleem. Het is eenvoudiger om de Routing Service elke keer de Itinerary opnieuw te laten doen.

😊 : Ja, maar het is voor ons extra werk om alle ondersteunende plannen voor een nieuwe Itinerary te maken, dus we willen niet omleiden tenzij de wijziging dat noodzakelijk maakt.

🤓 : Oh. Dan moeten we wat functionaliteit toevoegen aan de Route Specificatie. Als je dan iets in de specificatie verandert, kijken we of de route nog voldoet aan de specificatie. Zo niet, dan laten we de Routing Service het reisschema opnieuw genereren.

😊 : Je hoeft je hier geen zorgen over te maken bij vertrek of bestemming, omdat het reisschema dan altijd verandert.

🤓 : Prima, maar het is voor ons eenvoudiger om gewoon iedere keer de vergelijking te maken. De routebeschrijving wordt pas gegenereerd als niet meer aan de routespecificatie wordt voldaan.

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

Domeinexperts (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.