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 😊 : Wenn wir also die Zollabfertigungsstelle ändern, müssen wir den gesamten Routingplan neu erstellen.

Developer 🤓 : Genau. Wir löschen alle Zeilen in der Sendungstabelle mit dieser Fracht-ID, dann geben wir den Ursprung, das Ziel und den neuen Zollabfertigungspunkt an den Routing Service weiter, und dieser füllt die Tabelle neu auf. Wir müssen einen Booleschen Wert in der Fracht haben, damit wir wissen, dass es Daten in der Sendungstabelle gibt.

😊 : Die Zeilen löschen? OK, wie auch immer. Wie auch immer, wenn wir vorher überhaupt keinen Zollabfertigungspunkt hatten, müssen wir das Gleiche tun.

🤓 : Sicher, jedes Mal, wenn Sie den Ursprung, das Ziel oder den Zollabfertigungspunkt ändern (oder zum ersten Mal einen eingeben), prüfen wir, ob wir Sendungsdaten haben, und dann löschen wir sie und lassen sie vom Routing Service neu generieren.

😊 : Wenn die alte Verzollungsstelle zufällig die richtige ist, würden wir das natürlich nicht machen wollen.

🤓 : Oh, kein Problem. Es ist einfacher, den Routing Service die Be- und Entladungen jedes Mal neu durchführen zu lassen.

😊 : Ja, aber es ist zusätzliche Arbeit für uns, alle unterstützenden Pläne für eine neue Reiseroute zu erstellen, also wollen wir nicht umleiten, es sei denn, die Route macht es notwendig.

🤓 : Igitt. Nun, wenn Sie zum ersten Mal eine Zollabfertigungsstelle betreten, müssen wir die Tabelle abfragen, um die alte abgeleitete Zollabfertigungsstelle zu finden, und sie dann mit der neuen vergleichen. Dann wissen wir, ob wir es neu machen müssen.

😊 : Sie werden sich darüber keine Gedanken machen müssen, wenn Sie den Start- oder Zielort erreichen, da sich die Reiseroute dann immer ändert.

🤓 : Gut. Werden wir nicht.

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

😊 : Wenn wir also die Zollabfertigungsstelle ändern, müssen wir den gesamten Routingplan neu erstellen.

🤓 : Genau. Wenn Sie eines der Attribute in der Routenspezifikation ändern, löschen wir die alte Reiseroute und bitten den Routing Service, eine neue zu generieren, die auf der neuen Routenspezifikation basiert.

😊 : Wenn wir vorher überhaupt keine Zollabfertigungsstelle angegeben hatten, müssen wir das gleichzeitig tun.

🤓 : Sicher, immer wenn Sie etwas in der Routenspezifikation ändern, generieren wir die Reiseroute neu. Dazu gehört auch, dass Sie etwas zum ersten Mal eingeben.

😊 : Natürlich, wenn die alte Zollabfertigung zufällig die richtige ist, würden wir das nicht tun wollen.

🤓 : Oh, kein Problem. Es ist einfacher, wenn der Routing Service die Reiseroute jedes Mal neu erstellt.

😊 : Ja, aber es ist zusätzliche Arbeit für uns, alle unterstützenden Pläne für eine neue Reiseroute zu erstellen, also wollen wir die Reiseroute nicht neu erstellen, es sei denn, die Änderung macht es notwendig.

🤓 : Oh. Dann müssen wir der Routenspezifikation einige Funktionen hinzufügen. Wenn Sie dann etwas in der Spezifikation ändern, werden wir sehen, ob die Reiseroute immer noch der Spezifikation entspricht. Wenn dies nicht der Fall ist, wird der Routing Service die Reiseroute neu generieren.

😊 : Sie müssen sich darüber keine Gedanken machen, wenn Sie den Start- oder Zielort ändern, da sich die Reiseroute dann immer ändert.

🤓 : Gut, aber es wird einfacher für uns sein, den Vergleich jedes Mal durchzuführen. Der Reiseplan wird nur erstellt, wenn die Routenspezifikation nicht mehr erfüllt ist.

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

Domänenexperten (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).

In der gegenwärtigen Situation, in der die Sprache allgegenwärtig ist, können Domänenexperten und Entwickler bis zu einem gewissen Grad eine Sprache verwenden, die sich im Laufe der Zeit verändert hat, so dass sie eine bestimmte Sprache (Jargon/Kosakata) verwenden können. 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.