Komunikasi dengan Ubiquitous Language

Setelah tahu apa bisnisnya, kita perlu memahami bagaimana bisnis itu berjalan di level operasional. Bagian ini membawa kita memahami konsep bahasa umum (ubiquitous language) DDD untuk komunikasi dan penemuan pengetahuan domain.

Komunikasi dengan Ubiquitous Language.

Pengetahuan domain (domain knowledge) adalah semua pemahaman tentang dunia nyata yang sedang kita coba pecahkan lewat sistem/software yang kita bangun. Sistem/software adalah representasi digital dari realitas bisnis. Karena itu dalam DDD, langkah pertama adalah menemukan atau menggali pengetahuan domain, supaya tim engineering dan bisnis punya pemahaman yang sama tentang apa yang sebenarnya ingin diselesaikan.

Intinya, setiap kali kita mengembangkan sistem perangkat lunak, kita sebenarnya memecahkan masalah bisnis yang dihadapi perusahaan (misalnya, mengoptimalkan pengiriman paket FedEx atau melacak stok toko). Masalah bisnis ini rumit dan biasanya hanya diketahui oleh para ahli domain. Jika kita tidak bisa menggunakan istilah mereka, kita akan mudah salah paham tentang kebutuhan sistem.

Masalah umum dalam proyek pengembangan adalah hambatan komunikasi. Pengetahuan domain sering “diterjemahkan” berkali-kali: dari ahli domain (domain expert) ke analis, lalu ke dokumen syarat, lalu ke desain sistem, lalu ke kode program. Setiap penerjemahan seperti permainan bisik-bisikan: informasi penting bisa hilang atau bias. Akibatnya, tim developer bisa saja membangun solusi yang salah karena tidak sepenuhnya memahami masalah aslinya.

Ahli domain (domain expert) adalah orang yang benar-benar paham seluk-beluk dunia nyata yang sedang kita pecahkan lewat sistem/software. Mereka tidak harus bisa coding, tapi mereka tahu kenapa sesuatu harus dilakukan seperti itu dalam bisnis.

Untuk menghindari informasi penting yang hilang atau bias, DDD memperkenalkan konsep Ubiquitous Language, satu set istilah tunggal yang digunakan oleh semua pihak (pengembang, analis, ahli domain, bahkan UI/UX) ketika membicarakan domain bisnis. Artinya, jangan lagi menggunakan jargon teknis di antara ahli bisnis (business expert). Gunakan hanya istilah bisnis yang mudah dipahami semua orang. Misalnya, ketika merancang sistem manajemen kampanye iklan, semua orang harus sepakat pada frase seperti “kampanye”, “materi iklan”, “tayang”, bukan “iframe”, “record SQL” atau istilah IT lainnya yang mungkin tidak dipahami pihak bisnis.

Fase penemuan pengetahuan domain terjadi lewat kolaborasi aktif antara engineer, ahli domain, dan ahli bisnis.
Tujuannya bukan cuma mengumpulkan requirement, tapi menyatukan cara berpikir tentang masalah dan solusinya.

• Ahli bisnis membawa visi dan prioritas (“kita ingin menurunkan waktu pengiriman”).

• Ahli domain menjelaskan realitas dan batasan teknis di lapangan (“kalau hujan, kurir butuh rute alternatif”).

• Engineer menerjemahkan semua itu menjadi model domain dan bahasa umum yang bisa diimplementasikan di software.

Dengan analogi:

Ahli bisnis membantu menentukan arah perahu, ahli domain membantu menavigasi jalur aman, dan engineer membantu membangun perahunya.

Ubiquitous Language harus konsisten dan tepat. Setiap istilah harus punya satu arti yang jelas, tidak boleh ambigu atau punya sinonim ganda. Misalnya, jika di bisnis asuransi kata “polis” bisa berarti aturan regulasi atau kontrak asuransi, dalam bahasa umum kita harus meluruskannya menjadi dua istilah terpisah: “peraturan regulasi” dan “kontrak asuransi”. Begitu juga kita sebaiknya tidak mencampur istilah seperti “user”, “visitor”, dan “account” jika ternyata memiliki makna berbeda dalam bisnis, setiap istilah harus dipakai secara khusus sesuai konteks. Dengan begitu, tidak ada salah paham antar tim.

Secara keseluruhan, kita sebenarnya sedang membuat model domain bisnis menggunakan bahasa umum itu. Model di sini diibaratkan seperti peta: kita tidak menggambar semua detail bumi, hanya memilih aspek yang relevan untuk tujuan tertentu (misalnya peta jalan, peta metro, atau peta cuaca). Begitu pula model sistem. Contohnya, untuk sistem kampanye iklan, kita mungkin butuh entitas Campaign dengan field seperti id, is_published, dan daftar placements. Dalam kode Rust, misalnya:

struct Campaign {
    id: u32,
    title: String,
    placements: Vec<Placement>,
    is_published: bool,
    // field lainnya sesuai kebutuhan bisnis...
}

Model domain (domain model) adalah representasi mental dari bagaimana dunia bisnis bekerja, yang kita tuangkan ke dalam bentuk istilah, diagram, dan akhirnya kode. Model domain bukan sekadar diagram UML atau ERD, melainkan gabungan dari konsep, relasi, dan aturan bisnis yang disepakati oleh tim.
Contoh lainnya dalam sistem e-commerce:

• Entitas: Order, Product, Customer, Payment

• Relasi: Order berisi beberapa Product, dan terhubung dengan satu Customer

• Aturan bisnis: Order tidak bisa dikonfirmasi jika Payment belum berhasil

Model domain adalah jantung DDD, karena semua keputusan desain dan kode mengacu ke sana.

Ubiquitous language adalah kosakata yang disepakati bersama oleh semua pihak (developer, ahli domain, manajer, tester) untuk membicarakan hal-hal di dalam model domain.

• Kalau model domain berisi konsep dan relasi,
  maka bahasa umum adalah kata-kata yang dipakai untuk menyebut konsep-konsep itu.

• Bahasa umum harus muncul di percakapan, dokumentasi, dan kode.

Contoh:

• Kalau di bisnis disebut “pesanan dikonfirmasi”, maka di kode pun sebaiknya ada order.confirm() — bukan flag = true atau set_status(1).

• Kalau ahli domain menyebut “pengiriman gagal karena kurir kehabisan slot”, maka model domain perlu entitas CourierSchedule, bukan sekadar delivery_attempts.

Dengan begitu, software benar-benar mencerminkan cara berpikir orang bisnis, bukan sekadar logika teknis.

Dengan analogi:

Bayangkan kamu main “pesan berantai” di masa kecil, seseorang berbisik ke orang kedua, lalu diteruskan ke orang ketiga, dan seterusnya. Di akhir, pesan sering berubah total dari yang aslinya.

Nah, dalam proyek software tradisional:

1. Ahli domain (domain expert) menjelaskan masalah ke analis bisnis.

2. Analis menulis dokumen requirement.

3. Dokumen itu dibaca arsitek atau developer.

4. Developer menulis kode berdasarkan interpretasinya.

Di setiap tahap, arti bisa melenceng sedikit demi sedikit.
Hasil akhirnya: software yang secara teknis benar tapi secara bisnis bisa salah.

Dengan DDD, kita memotong rantai itu: developer bicara langsung dengan ahli domain, memakai bahasa umum yang sama, sehingga model yang tertulis di kode benar-benar mewakili pemahaman bisnis yang sebenarnya. Hasilnya, pengembang dapat membuat kode (dan model data) yang betul-betul sesuai dengan pemikiran dan kebutuhan bisnis, sehingga sedikit konflik ketika kebutuhan berubah.

Model data biasanya berarti struktur penyimpanan, tabel di database, kolom, tipe data, relasi. Fokusnya: bagaimana data disimpan dan diakses secara efisien.
Contohnya:

struct OrderRow {
    id: i64,
    customer_id: i64,
    status_code: i32,
    created_at: DateTime<Utc>,
}

Sedangkan model domain berfokus pada logika dan aturan bisnis, bagaimana entitas berperilaku dan saling berinteraksi.
Contohnya:

struct Order {
    id: OrderId,
    customer: CustomerId,
    items: Vec<OrderItem>,
    status: OrderStatus,
}

impl Order {
    fn confirm(&mut self) -> Result<(), &’static str> {
        if self.items.is_empty() {
            Err(”order must have items before confirmation”)
        } else {
            self.status = OrderStatus::Confirmed;
            Ok(())
        }
    }
}

Dalam DDD, model domain adalah pusatnya, sedangkan model data hanyalah salah satu cara menyimpan informasi dari model domain.
Jadi, relasi antara keduanya seperti: “Model domain menjelaskan makna bisnisnya, model data menyimpan faktanya.”

Referensi

Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.