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 😊 : Então quando mudamos o ponto de desalfandegamento, precisamos refazer todo o plano de roteamento.

Developer 🤓 : Certo. Apagaremos todas as linhas da tabela de embarque com esse id de carga, então passaremos a origem, destino e o novo ponto de desembaraço aduaneiro para o Serviço de Roteamento, e ele re-populará a tabela. Teremos que ter um Booleano na Carga para sabermos que há dados na tabela de embarque.

😊 : Apagar as filas? OK, tanto faz. De qualquer forma, se antes não tínhamos um ponto de desembaraço aduaneiro, teremos que fazer a mesma coisa.

🤓 : Claro, sempre que você mudar a origem, destino ou ponto de desembaraço aduaneiro (ou digitar um pela primeira vez), vamos verificar se temos dados de embarque e depois vamos apagá-los e depois deixar o Serviço de Roteamento regenerá-los.

😊 : Claro que, se o antigo desalfandegamento fosse o correcto, não queremos fazer isso.

🤓 : Oh, não há problema. É mais fácil apenas fazer o Serviço de Roteamento refazer as cargas e descargas toda vez.

😊 : Sim, mas é trabalho extra para nós fazer todos os planos de suporte para um novo itinerário, então não queremos redirecionar a menos que a canga o exija.

🤓 : Ugh. Bem, então, se você está entrando num ponto de desalfandegamento pela primeira vez, teremos que consultar a tabela para encontrar o antigo ponto de desalfandegamento derivado, e depois compará-lo com o novo. Então saberemos se precisamos refazê-lo.

😊 : Não terá que se preocupar com isso na origem ou no destino, já que o itinerário sempre mudaria então.

🤓 : Bom. Nós não.

Sekarang perhatikan diagram dan percakapan berikut. A percakapan eang sama persis, tetapi menggunakan bahasa (kosakata) eang berbeda.

Percakapan 2 – Modelo de Domínio Enriquecido para Apoiar a Discussão

😊 : Então quando mudamos o ponto de desalfandegamento, precisamos refazer todo o plano de roteamento.

🤓 : Certo. Quando você mudar qualquer um dos atributos na Especificação de Rota, vamos apagar o Itinerário antigo e pedir ao Serviço de Roteamento para gerar um novo baseado na nova Especificação de Rota.

😊 : Se não tivéssemos especificado um ponto de desalfandegamento antes, teremos que fazer isso ao mesmo tempo.

🤓 : Claro, sempre que você mudar qualquer coisa na Especificação de Rota, vamos regenerar o Itinerário. Isso inclui introduzir algo pela primeira vez.

😊 : Claro, se o velho desalfandegamento fosse o correcto, não queremos fazer isso.

🤓 : Oh, não há problema. É mais fácil fazer o Serviço de Roteiro refazer o Itinerário toda vez.

😊 : Sim, mas é trabalho extra para nós fazer todos os planos de suporte para um novo Itinerário, então não queremos redirecionar a não ser que a mudança o exija.

🤓 : Oh. Então teremos que adicionar alguma funcionalidade à Especificação de Rota. Então, sempre que você mudar alguma coisa na Especificação, veremos se o Itinerário ainda satisfaz a Especificação. Se não, teremos o Serviço de Roteiro regenerar o Itinerário.

😊 : Você não terá que se preocupar com isso na origem ou destino, já que o Itinerário sempre mudaria então.

🤓 : Tudo bem, mas será mais simples para nós apenas fazer a comparação a cada vez. O Itinerário só será gerado quando a Especificação de Rota não estiver mais satisfeita.

Gambar dibawah ini mengilustrasikan domain experts dan software developers yang sedang berdiskusi. A Gambar sebelah é uma empresa que desenvolve software (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).

Peritos de domínio (do Inglês como 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.