Domain-Driven Design: Tackling Complexity in the Heart of Software

Seorang developer duduk bersama pakar bisnis di sebuah perusahaan asuransi.

Pakar bisnis bicara soal "polis", "klaim", "premi", "underwriting". Developer mengangguk, lalu pulang ke mejanya dan menulis kode dengan nama kelas seperti Record, Handler, Manager, Processor.

Dua bulan kemudian, tidak ada satu pun dari mereka yang bisa benar-benar memahami sistem itu tanpa penerjemah.

Eric Evans melihat pola ini berulang di proyek demi proyek selama kariernya sebagai konsultan software. Bukan karena timnya bodoh. Karena tidak ada yang secara sadar menjaga agar bahasa bisnis dan bahasa kode tetap sama.

Dari situ lahir buku ini, hasil pengamatan bertahun-tahun Evans terhadap proyek-proyek software kompleks yang berhasil, dan yang gagal total karena kompleksitasnya sendiri.

Premis utamanya sederhana untuk diucapkan, tapi sulit dijalankan konsisten: model perangkat lunak Anda harus mencerminkan pemahaman domain bisnis secara akurat, dan bahasa yang dipakai developer dan pakar bisnis harus benar-benar sama, bukan cuma mirip.

Evans menyebutnya ubiquitous language, bahasa yang dipakai di mana-mana, di percakapan, di dokumentasi, dan yang paling penting, di dalam kode itu sendiri.

Bagian 1: Ubiquitous Language, Kenapa Nama Variabel Anda Lebih Penting dari yang Anda Kira

Coba tanya diri Anda, seberapa sering nama kelas atau fungsi di kode Anda sama persis dengan istilah yang dipakai orang bisnis saat menjelaskan proses mereka?

Kalau jawabannya jarang, menurut Evans, Anda sedang membangun dua model sekaligus tanpa sadar: satu di kepala orang bisnis, satu lagi di kode Anda. Dan keduanya perlahan akan bergeser saling menjauh.

Bahasa yang Hidup di Dalam Kode

Ubiquitous language bukan sekadar glosarium yang ditulis sekali lalu dilupakan. Evans menekankan bahasa ini harus terus dipakai dalam percakapan sehari-hari tim, sekaligus tercermin langsung di nama kelas, method, dan variabel dalam kode.

“The vocabulary of that Ubiquitous Language includes the names of classes and prominent operations.”

Ketika istilah bisnis berubah, seperti "klaim" yang mulai dipecah jadi "klaim awal" dan "klaim lanjutan", kode Anda seharusnya ikut berubah mengikuti pergeseran bahasa itu, bukan tetap memakai istilah lama yang sudah tidak relevan.

Biaya membangun bahasa bersama ini memang tidak murah. Tapi Evans mengingatkan, biaya komunikasi yang buruk jauh lebih mahal dalam jangka panjang, biasanya muncul belakangan dalam bentuk bug yang sulit dilacak dan fitur yang salah paham dari awal.

Bagian 2: Bounded Context, Kenapa Satu Kata Bisa Berarti Dua Hal Berbeda dan Itu Tidak Apa-apa

Bayangkan kata "pelanggan" dalam sistem e-commerce Anda.

Di tim penjualan, pelanggan berarti orang yang aktif membeli, lengkap dengan riwayat transaksi dan preferensi produk. Di tim keuangan, pelanggan berarti entitas dengan tagihan dan status pembayaran.

Sama-sama "pelanggan". Tapi maknanya berbeda tergantung konteksnya.

Batas yang Menyelamatkan Anda dari Model Raksasa yang Kacau

Inilah yang Evans sebut bounded context, batas eksplisit tempat sebuah model dan bahasanya berlaku konsisten. Di luar batas itu, istilah yang sama boleh saja berarti lain, dan itu bukan masalah selama batasnya jelas.

Kesalahan umum yang Evans amati, tim mencoba memaksakan satu model raksasa yang mencakup seluruh perusahaan, berharap semua istilah punya satu makna tunggal di mana-mana. Hasilnya biasanya model yang terlalu umum sampai kehilangan makna, atau terlalu rumit sampai tidak ada yang benar-benar memahaminya secara utuh.

Dengan memecah sistem jadi beberapa bounded context, tiap tim bisa punya model yang tajam dan relevan untuk konteks kerjanya sendiri, tanpa harus berkompromi demi konsistensi semu di seluruh organisasi.

Bagian 3: Context Map, Menggambar Hubungan Antar Dunia yang Berbeda

Kalau setiap bounded context punya bahasa dan modelnya sendiri, bagaimana mereka saling berkomunikasi?

Evans menjawabnya lewat context mapping, teknik menggambarkan secara eksplisit bagaimana berbagai bounded context saling berhubungan dan saling memengaruhi.

Peta yang Mencegah Kesalahpahaman Antar Tim

Tanpa context map, tim yang bekerja di context berbeda sering saling berasumsi tentang model satu sama lain, dan asumsi itu biasanya salah. Sistem pembayaran mengira sistem pengiriman punya struktur data tertentu, padahal tidak, dan kesalahan itu baru ketahuan saat integrasi sudah berjalan.

Context map memaksa tim untuk secara sadar mendefinisikan jenis hubungan antar context, apakah satu context jadi "hulu" yang mendikte model ke context lain, atau keduanya harus saling menyesuaikan lewat lapisan penerjemah khusus.

Bagi tim yang sedang memecah sistem monolitik jadi microservices, prinsip bounded context dan context map ini menjadi salah satu fondasi paling relevan, karena batas antar microservice pada dasarnya adalah batas antar bounded context yang sudah lebih dulu dipikirkan Evans jauh sebelum istilah microservices populer.

Bagian 4: Entity dan Value Object, Perbedaan yang Sering Diabaikan Tapi Krusial

Ada dua jenis objek dalam model domain yang menurut Evans sering dicampuradukkan begitu saja: entity dan value object.

Entity: Identitas yang Bertahan Meski Datanya Berubah

Seorang pelanggan tetaplah pelanggan yang sama, meski nomor teleponnya berganti, alamatnya pindah, atau namanya diperbarui. Identitasnya yang membuatnya unik, bukan atribut-atributnya. Inilah entity.

Value Object: Objek yang Didefinisikan Sepenuhnya oleh Nilainya

Sebaliknya, alamat pengiriman atau rentang tanggal tidak punya identitas unik tersendiri. Dua alamat dengan data persis sama secara efektif adalah alamat yang sama, bisa saling dipertukarkan tanpa masalah. Inilah value object.

Kedengarannya seperti detail teknis kecil, tapi Evans menekankan kesalahan memperlakukan value object seolah punya identitas unik, atau sebaliknya, sering jadi sumber bug tersembunyi dan kompleksitas yang tidak perlu di model domain Anda.

Bagian 5: Refactoring Menuju Pemahaman yang Lebih Dalam

Kebanyakan orang menganggap refactoring cuma soal membersihkan kode agar lebih rapi.

Evans punya pandangan yang lebih ambisius: refactoring seharusnya juga jadi proses memperdalam pemahaman Anda terhadap domain itu sendiri.

Model Bukan Sesuatu yang Dibuat Sekali Lalu Selesai

Saat pertama kali membangun model, pemahaman Anda terhadap domain masih dangkal. Seiring waktu, percakapan dengan pakar bisnis akan mengungkap nuansa yang tidak terlihat di awal, dan model Anda harus terus direvisi mengikuti pemahaman yang makin dalam ini.

Evans mendorong tim untuk tidak takut merombak model yang sudah "berfungsi", kalau ternyata model itu belum benar-benar mencerminkan realita bisnis. Menjaga model tetap dangkal demi kenyamanan sesaat, menurutnya, hanya menunda masalah yang jauh lebih besar di kemudian hari.

Proses iteratif inilah yang menjadi jantung dari domain-driven design secara keseluruhan, sebuah siklus tanpa akhir antara belajar, memodelkan, dan merefaktor, bukan proyek dengan titik "selesai" yang pasti.

Pelajaran untuk Hari Ini

1. Samakan Bahasa Kode Anda dengan Bahasa Pakar Bisnis Setiap kali istilah bisnis berubah, cek apakah nama kelas dan fungsi di kode Anda juga perlu ikut diperbarui.

2. Jangan Paksakan Satu Model Raksasa untuk Seluruh Sistem Definisikan batas bounded context dengan jelas, dan terima bahwa istilah yang sama boleh berarti lain di konteks berbeda.

3. Gambar Context Map Sebelum Mengintegrasikan Sistem Berbeda Jangan berasumsi soal model tim lain. Definisikan secara eksplisit jenis hubungan antar bagian sistem sebelum masalah integrasi muncul.

4. Perlakukan Refactoring sebagai Kesempatan Memperdalam Pemahaman Domain Jangan cuma membersihkan kode. Gunakan momen refactoring untuk mengevaluasi ulang apakah model Anda masih mencerminkan realita bisnis dengan akurat.

Penutup

Domain-Driven Design bukan buku yang mudah dibaca sekali duduk. Evans menulisnya dengan gaya yang padat dan penuh istilah baru, dan banyak orang butuh beberapa kali baca ulang untuk benar-benar memahaminya secara utuh.

Tapi bagi siapa pun yang pernah frustrasi melihat sistem software yang secara teknis berjalan tapi tidak ada yang benar-benar memahaminya, buku ini menawarkan kerangka berpikir yang jarang dibahas di tempat lain, yaitu bahwa kompleksitas software paling berbahaya bukan datang dari algoritma yang rumit, melainkan dari kesenjangan pemahaman antara orang-orang yang membangunnya.

Di era microservices dan sistem terdistribusi, konsep bounded context yang ditulis Evans dua dekade lalu justru terasa semakin relevan, karena batas antar layanan yang baik pada dasarnya adalah cerminan dari batas pemahaman domain yang jelas, bukan sekadar keputusan teknis semata.

Pertanyaan untuk Anda, kapan terakhir kali Anda dan pakar bisnis di tim Anda benar-benar memakai istilah yang persis sama, baik saat mengobrol maupun saat membaca kode?

Tentang Buku Asli