Apa itu ubiquitous language dalam Domain-driven Design (DDD)?

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 😊 : So when we change the customs clearance point, we need to redo the whole routing plan.

Developer 🤓 : Right. We’ll delete all the rows in the shipment table with that cargo id, then we’ll pass the origin, destination, and the new customs clearance point into the Routing Service, and it will re-populate the table. We’ll have to have a Boolean in the Cargo so we’ll know there is data in the shipment table.

😊 : Delete the rows? OK, whatever. Anyway, if we didn’t have a customs clearance point at all before, we’ll have to do the same thing.

🤓 : Sure, anytime 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.

😊 : Of course, if the old customs clearance just happended to be the right one, we wouldn’t want to do that.

🤓 : Oh, no problem. It’s easier to just make the Routing Service redo the loads and unloads every time.

😊 : Yes, but it’s extra work for us to make all the supporting plans for a new itinerary, so we don’t want to reroute unless the cange necessitates it.

🤓 : Ugh. Well, then, if you are entering a customs clearance point for the first time, we’ll have to query the table to find the old derived customs clearance point, and then compare it to the new one. Then we’ll know if we need to redo it.

😊 : You won’t have to worry about this on origin or destination, since the itinerary would always change then.

🤓 : Good. We won’t.

Percakapan 2: Domain Model Enriched to Support Discussion

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

😊 : So when we change the customs clearance point, we need to redo the whole routing plan.

🤓 : Right. 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 hadn’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 the Route Spec, we’ll regenerate the Itinerary. That includes entering something for the first time.

😊 : Of course, if the old customs clearance just happended to be the right one, we wouldn’t want to do that.

🤓 : Oh, no problem. It’s easier to just make the Routing Service redo the Itinerary every time.

😊 : Yes, but it’s extra work for us to make all the supporting plans for a new Itinerary, so we don’t want to reroute unless the change necessitates it.

🤓 : Oh. Then we’ll have to add some functionality to the Route Specification. Then, whenever you change anything in the Spec, we’ll see if the Itinerary still satisfies the Specification. If it doesn’t, we’ll have the Routing Service regenerate the Itinerary.

😊 : You won’t have to worry about this on origin or destination, since the Itinerary would always change then.

🤓 : Fine, but it will be simpler for us to just do the comparison every time. The Itinerary will only be generated when the Route Specification is no longer satisfied.

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

Domain experts (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.

Tulisan ini diterjemahkan dan disarikan dari Domain-Driven Design karya Eric Evans dan Domain-Driven Design Distilled karya Vaughn Vernon.