Materi Pengenalan

Domain Driven Design

Cara membangun perangkat lunak yang benar-benar sesuai dengan dunia nyata — menggunakan bahasa yang dipahami semua orang

Mengapa kita butuh DDD?
Bayangkan kamu diminta membangun aplikasi untuk sebuah rumah sakit. Kamu mulai coding... lalu 3 bulan kemudian dokternya bilang: "Ini bukan yang kami maksud sama sekali." Itulah masalah yang DDD coba selesaikan.
ANALOGI — ARSITEK DAN PEMILIK RUMAH
Bayangkan kamu adalah arsitek. Klien bilang "saya mau rumah yang nyaman". Kalau kamu langsung bangun tanpa banyak tanya, hasilnya mungkin bagus menurut selera arsitek — tapi tidak sesuai keinginan klien. DDD mengajarkan arsitek (programmer) untuk ngobrol dalam, sering, dan dalam bahasa yang sama dengan klien (bisnis).
Masalah klasik software
Developer membuat sistem yang secara teknis benar, tapi secara bisnis salah. Fitur tidak sesuai kebutuhan. Nama variabel berbeda dengan istilah bisnis. Komunikasi putus di tengah jalan.
Solusi DDD
DDD menjembatani dunia bisnis dan dunia teknis. Caranya? Bangun software berdasarkan domain — yaitu masalah bisnis nyata yang ingin diselesaikan — bukan berdasarkan asumsi programmer.
INTINYA
DDD bukan tentang teknologi. DDD tentang memahami masalah bisnis lalu menerjemahkannya ke dalam kode. Teknologinya nanti menyesuaikan.
2003
Pertama diperkenalkan oleh Eric Evans
3
Pilar utama: Domain, Model, Bahasa Bersama
1 tujuan
Software yang benar-benar mencerminkan bisnis
Apa itu Domain?
Domain adalah bidang atau area masalah dari sebuah bisnis. Kalau kamu membuat software untuk rumah sakit, maka "kesehatan pasien" adalah domain-nya. Kalau untuk toko online, maka "penjualan produk" adalah domain-nya.
ANALOGI — RESTORAN
Sebuah restoran punya banyak urusan: dapur (memasak makanan), kasir (pembayaran), pelayan (melayani tamu), dan gudang (stok bahan). Masing-masing ini adalah sub-domain. Mereka punya aturan sendiri-sendiri, tapi semuanya bekerja untuk satu tujuan: membuat tamu makan dengan puas.
Contoh: Sub-domain sebuah Restoran
🍳
Dapur
Core Domain
💳
Kasir
Supporting Domain
📦
Stok Bahan
Supporting Domain
🧑‍🤝‍🧑
Pelayan
Supporting Domain
🗓️
Reservasi
Generic Domain
⭐
Ulasan
Generic Domain
TIPE 01

Core Domain

Ini inti bisnis kamu. Yang membuat kamu berbeda dari kompetitor. Harus dibangun sendiri dan dengan sangat baik. Contoh: Algoritma memasak rahasia di restoran.

TIPE 02

Supporting Domain

Mendukung core domain, tapi bukan yang utama. Bisa dibangun sendiri tapi tidak perlu sempurna. Contoh: Sistem pencatatan pesanan pelanggan.

TIPE 03

Generic Domain

Masalah umum yang sudah banyak solusinya. Sebaiknya pakai produk jadi saja. Contoh: Sistem login, notifikasi email, kalender reservasi.

KUNCI

Domain Model

Gambaran sederhana (peta) dari sebuah domain. Bukan kode! Ini adalah cara kita memetakan aturan bisnis ke dalam struktur yang bisa dipahami semua pihak.

Bahasa Bersama (Ubiquitous Language)
Ini adalah salah satu konsep paling penting dalam DDD. Satu kata yang sama, digunakan oleh semua orang — baik dokter, manajer, maupun programmer — dengan arti yang sama persis.
ANALOGI — DOKTER DAN PASIEN
Dokter bilang "tekanan darah sistolik 120". Kalau kamu tidak tahu artinya, komunikasi gagal. DDD bilang: kita harus cari kata-kata yang dipahami SEMUA pihak. Bukan dokter yang harus belajar coding, bukan programmer yang harus jadi dokter — tapi keduanya sepakat pada istilah bersama.
TANPA BAHASA BERSAMA
  • Bisnis: "Pelanggan"
  • Database: tabel "user"
  • Code: variabel "person"
  • API: field "client"
  • Semua maksudnya sama, tapi nama berbeda → bingung!
DENGAN BAHASA BERSAMA
  • Bisnis: "Pelanggan"
  • Database: tabel "pelanggan"
  • Code: class Pelanggan
  • API: field "pelanggan"
  • Satu kata, satu makna, semua mengerti!
KENAPA INI PENTING?
Bayangkan rapat antara manajer dan programmer. Manajer bilang "kita perlu fitur untuk pembatalan order". Programmer mengangguk, tapi dalam pikirannya dia buat fitur hapus order. Padahal bisnis butuh yang berbeda! Ubiquitous Language mencegah miskomunikasi ini dari awal.
Cara membangun Bahasa Bersama
Ngobrol dengan ahli bisnis
→
Catat istilah penting
→
Sepakati definisi
→
Pakai dalam kode & dokumen
Jika ada istilah yang berbeda antar departemen, cari tahu mengapa. Mungkin memang maknanya berbeda — dan itu berarti kamu punya dua konteks yang berbeda (Bounded Context).
Blok Pembangun DDD
DDD punya beberapa "bata" untuk membangun sistem. Masing-masing punya peran berbeda, seperti bagian-bagian berbeda dalam sebuah bangunan.
ANALOGI — KOTA
Sebuah kota terdiri dari berbagai elemen: rumah (Entity), nomor rumah (Value Object), kepala desa (Aggregate Root), pengumuman warga (Domain Event), dan kantor pos (Repository). Semua punya fungsi berbeda, semua saling bekerja sama.
BLOK 01
Entity

Entitas

Objek yang punya identitas unik. Walau sifatnya berubah, dia tetap objek yang sama. Contoh: Kamu adalah kamu, walau rambutmu sudah berubah sejak SD.

BLOK 02
Value Object

Objek Nilai

Objek yang tidak punya identitas. Didefinisikan dari nilainya saja. Contoh: "Rp 50.000" adalah Rp 50.000. Tidak peduli uang kertas mana — nilainya sama.

BLOK 03
Aggregate

Agregat

Sekumpulan Entity dan Value Object yang diperlakukan sebagai satu unit. Punya satu "kepala" (Aggregate Root). Contoh: Pesanan = kepala + item-item pesanan.

BLOK 04
Repository

Repository

Tempat menyimpan dan mengambil Aggregate. Seperti lemari arsip. Kamu tidak perlu tahu bagaimana data disimpan di dalamnya — kamu cukup minta dan dapat.

BLOK 05
Domain Event

Event Domain

Sesuatu penting yang sudah terjadi di domain. Seperti pengumuman. Contoh: "Pesanan Dibuat", "Pembayaran Diterima", "Barang Dikirim".

BLOK 06
Domain Service

Layanan Domain

Operasi bisnis yang tidak cocok ditempatkan di satu Entity saja. Contoh: "Transfer uang" melibatkan dua rekening berbeda — jadi jadi satu Service tersendiri.

Contoh nyata: Sistem Pemesanan Pizza
Entity: Pesanan #001 Value Object: Harga Rp 80.000 Aggregate: Pesanan + Item Pizza Repository: Simpan/ambil Pesanan Event: "Pesanan Masuk Dapur" Service: Hitung Total Diskon
Batasan Konteks (Bounded Context)
Dalam sistem besar, kata yang sama bisa berarti hal berbeda di bagian yang berbeda. Bounded Context adalah "pagar" yang memisahkan area-area ini agar tidak saling bingung.
ANALOGI — KATA "AKUN"
Di bagian keuangan, "akun" berarti rekening bank. Di bagian IT, "akun" berarti akun login pengguna. Di bagian sales, "akun" berarti data klien perusahaan. Kata sama, tapi arti SANGAT berbeda! Bounded Context memberi pagar: di dalam konteks Keuangan, "akun" hanya berarti satu hal.
Contoh sistem e-commerce dengan beberapa Bounded Context:
Konteks Katalog
Produk, Kategori, Harga
Konteks Pesanan
Order, Keranjang, Checkout
Konteks Pembayaran
Invoice, Transaksi, Refund
Konteks Pengiriman
Paket, Kurir, Rute
Konteks Pelanggan
Profil, Alamat, Poin
Konteks Laporan
Statistik, Grafik, Export
"Produk" di Konteks Katalog ≠ "Produk" di Konteks Pengiriman. Keduanya punya makna berbeda di dalam pagarnya masing-masing.
Manfaat Bounded Context
Tim bisa bekerja mandiri per konteks tanpa saling ganggu. Kode menjadi lebih bersih dan fokus. Perubahan di satu konteks tidak merusak konteks lain.
Context Map
Peta yang menunjukkan hubungan antar Bounded Context. Seperti peta kota yang menunjukkan jalan penghubung antar kelurahan. Penting untuk memahami alur data.
TIPS PRAKTIS DI KELAS
Coba petakan sistem kampus kalian! Bounded Context bisa meliputi: Akademik (mata kuliah, KRS), Keuangan (SPP, beasiswa), Perpustakaan (peminjaman, denda), Kemahasiswaan (organisasi, kegiatan). Setiap konteks punya "mahasiswa"-nya sendiri dengan data yang berbeda.
Latihan Pemahaman
Uji pemahaman kamu tentang konsep-konsep DDD yang sudah dipelajari. Pilih jawaban yang paling tepat!