Pengertian DDD ( Domain - Driven Design )
DDD (Domain-Driven Design) adalah pendekatan dalam pengembangan perangkat lunak yang fokus utamanya adalah memahami dan memodelkan logika bisnis (domain) secara mendalam dan menjadikannya pusat dari desain sistem.
DDD dirancang untuk mengatasi kompleksitas dalam aplikasi bisnis dengan cara memusatkan pengembangan software pada domain bisnis itu sendiri — bukan sekadar pada teknologi, fitur, atau framework.
| Konsep | Penjelasan Singkat |
|---|---|
| Domain | Area bisnis yang sedang kamu bangun (misal: e-commerce, perbankan, logistik) |
| Entity | Objek yang punya identitas unik dan berubah seiring waktu (misal: User, Order) |
| Value Object | Objek yang hanya peduli pada nilainya, bukan identitas (misal: Alamat, Uang) |
| Aggregate | Kumpulan objek yang dikelola sebagai satu unit |
| Repository | Abstraksi untuk akses data (misal: ambil produk dari database) |
| Service | Logika bisnis yang tidak cocok dimasukkan ke Entity atau VO |
| Bounded Context | Batasan konteks yang memisahkan satu model domain dari yang lain, untuk menghindari konflik istilah dan logika |
Intinya DDD ini, membuat pengembangan yang dibagi berdasarkan Domainnya. Pembagian area domain itu berdasarkan area logika bisnis. Misalnya dalam suatu aplikasi E-commerce pembagian domain bisa menjadi
/app
└── Domains/
├── User/ ← semua logika tentang pengguna
│ ├── Entities/
│ ├── Services/
│ ├── Repositories/
│ └── ValueObjects/
│
├── Product/ ← pengelolaan produk
│ ├── Entities/
│ ├── Services/
│ ├── Repositories/
│ └── ValueObjects/
│
├── Order/ ← pemesanan, pembayaran
│ ├── Entities/
│ ├── Services/
│ ├── Repositories/
│ └── ValueObjects/
│
├── Cart/ ← keranjang belanja
│ ├── Entities/
│ ├── Services/
│ └── Repositories/
│
└── Inventory/ ← manajemen stok
├── Entities/
├── Services/
└── Repositories/
Prinsip Pembagian:
- Satu domain = satu urusan logika bisnis.
Misalnya, domainOrdercuma ngurus pemesanan, bukan login user atau stok barang. - Masing-masing domain punya Entity, Service, dan Repository sendiri.
Jadi mereka tidak saling campur kecuali lewat interface. - Pakai Value Object untuk hal yang tidak punya identitas unik.
Contoh: alamat, nama, uang, ukuran, dsb. - Gunakan Domain Service jika logika tidak cocok disimpan di Entity atau VO ( value object ).
Kode di domain (Entity, VO, Domain Service) hanya fokus ke logika bisnis, tidak berurusan dengan teknis. - Domain nggak boleh tahu soal database atau framework
(seperti Laravel Eloquent, SQL, HTTP Request). Itu urusan Infrastructure layer.
Tujuan digunakannya metode ini untuk :
- Kode lebih modular
- Mudah dites dan dipahami
- Bisa dikembangkan oleh tim yang berbeda tanpa saling tabrak
- Mencegah logika bisnis tersebar di mana-mana (anti spaghetti code)
Dengan menggunakan konsep ini, diharapkan development menjadi lebih scalable dan efisien.
Konsep ini hampir mirip dengan Clean Architecture tapi sebenarnya beda fokus. Kita bahas di sini untuk Clean Architecture.
