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

Percakapan 1 – Abstraction minimale du domaine

User 😊 : Donc, lorsque nous changeons le point de dédouanement, nous devons refaire tout le plan de routage.

Developer 🤓 : Exact. Nous allons supprimer toutes les lignes de la table d’expédition avec cet id de cargaison, puis nous passerons l’origine, la destination et le nouveau point de dédouanement dans le service de routage, et il remplira à nouveau la table. Nous devrons avoir un booléen dans le Cargo pour savoir qu’il y a des données dans la table d’expédition.

😊 : Supprimer les lignes ? OK, peu importe. De toute façon, si nous n’avions pas du tout de point de dédouanement avant, nous devrons faire la même chose.

🤓 : Bien sûr, chaque fois que vous changez l’origine, la destination ou le point de dédouanement (ou que vous en entrez un pour la première fois), nous vérifierons si nous avons des données d’expédition et nous les supprimerons, puis nous laisserons le service de routage les régénérer.

😊 : Bien sûr, si l’ancien dédouanement se trouvait être le bon, nous ne voudrions pas faire cela.

🤓 : Oh, pas de problème. C’est plus facile de faire en sorte que le service de routage refasse les chargements et déchargements à chaque fois.

😊 : Oui, mais c’est du travail supplémentaire pour nous de faire tous les plans de soutien pour un nouvel itinéraire, donc nous ne voulons pas rerouter à moins que le cange ne le nécessite.

🤓 : Ugh. Bon, alors, si vous entrez dans un point de dédouanement pour la première fois, nous devrons interroger la table pour trouver l’ancien point de dédouanement dérivé, puis le comparer au nouveau. Nous saurons alors si nous devons le refaire.

😊 : Vous n’aurez pas à vous soucier de cela sur l’origine ou la destination, puisque l’itinéraire changerait toujours alors.

🤓 : Bien. Nous ne le ferons pas.

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

Percakapan 2 – Modèle de domaine enrichi pour soutenir la discussion

😊 : Donc quand on change le point de dédouanement, on doit refaire tout le plan de routage.

🤓 : Exact. Lorsque vous modifiez l’un des attributs de la spécification d’itinéraire, nous supprimons l’ancien itinéraire et demandons au service de routage d’en générer un nouveau basé sur la nouvelle spécification d’itinéraire.

😊 : Si nous n’avions pas du tout spécifié de point de dédouanement auparavant, nous devrons le faire en même temps.

🤓 : Bien sûr, chaque fois que vous modifiez quoi que ce soit dans la spécification d’itinéraire, nous régénérons l’itinéraire. Cela inclut l’entrée de quelque chose pour la première fois.

😊 : Bien sûr, si l’ancien dédouanement se trouve être le bon, nous ne voudrions pas faire cela.

🤓 : Oh, pas de problème. C’est plus facile de faire en sorte que le service de routage refasse l’itinéraire à chaque fois.

😊 : Oui, mais c’est un travail supplémentaire pour nous de faire tous les plans de soutien pour un nouvel itinéraire, donc nous ne voulons pas rerouter à moins que le changement ne le nécessite.

🤓 : Oh. Alors nous devrons ajouter une fonctionnalité à la spécification de l’itinéraire. Ensuite, chaque fois que vous changerez quelque chose dans la spécification, nous verrons si l’itinéraire satisfait toujours à la spécification. Si ce n’est pas le cas, nous demanderons au service de routage de régénérer l’itinéraire.

😊 : Vous n’aurez pas à vous en préoccuper sur l’origine ou la destination, puisque l’itinéraire changera toujours alors.

🤓 : Bien, mais il sera plus simple pour nous de faire la comparaison à chaque fois. L’Itinéraire ne sera généré que lorsque la spécification d’itinéraire n’est plus satisfaite.

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

Les experts de domaine (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 akan dunia kargo).

Dans la situation actuelle, le langage omniprésent se répand, et les experts de domaine et les développeurs peuvent, grâce à leurs connaissances, trouver les mots qui leur conviennent le mieux, car ils utilisent des termes (jargon/kosakata) qui leur sont familiers. 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).

Diagramme venn dibawah adalah ilustrasi untuk menggambarkan ubiquitous language.

.