Domain Driven Design (DDD): Cara Mengatasi Kompleksitas dalam Software

Dalam pengembangan aplikasi, masalah yang dihadapi developer tidak selalu berkaitan dengan kode atau teknologi. Semakin kompleks sebuah bisnis, semakin banyak pula aturan, proses, istilah, dan hubungan antarbagian yang harus dipahami oleh sistem. Jika struktur aplikasi tidak mencerminkan cara bisnis tersebut bekerja, kode dapat menjadi sulit dipahami dan dikembangkan.

Salah satu pendekatan yang digunakan untuk menghadapi kompleksitas tersebut adalah Domain Driven Design (DDD). Pendekatan ini berfokus pada pemodelan software berdasarkan domain bisnis, sehingga aturan dan konsep penting dalam bisnis dapat tercermin dengan jelas di dalam desain aplikasi.

DDD tidak sekadar membahas bagaimana membuat class, database, atau API. Pendekatan ini juga mendorong developer dan pihak bisnis untuk membangun pemahaman yang sama mengenai masalah yang sedang diselesaikan. Konsep seperti Ubiquitous Language, Bounded Context, Entity, Value Object, Aggregate, dan Domain Event menjadi bagian penting dalam penerapannya.

Apa Itu Domain Driven Design (DDD)?

Domain Driven Design (DDD) adalah pendekatan dalam desain dan pengembangan software yang menempatkan domain bisnis dan kompleksitas bisnis sebagai dasar utama dalam membangun model aplikasi. Dengan DDD, struktur dan perilaku software dirancang agar dapat merepresentasikan konsep, aturan, serta proses yang benar-benar digunakan dalam bisnis.

Istilah Domain Driven Design diperkenalkan oleh Eric Evans melalui bukunya Domain-Driven Design: Tackling Complexity in the Heart of Software yang diterbitkan pada 2003. Gagasan utamanya adalah bahwa pengembangan software untuk domain yang kompleks membutuhkan model yang mencerminkan pemahaman terhadap bisnis, bukan hanya struktur teknis seperti tabel database atau framework yang digunakan.

Sebagai contoh, aplikasi e-commerce tidak hanya terdiri dari tabel pelanggan, produk, dan pesanan. Di dalamnya terdapat aturan seperti bagaimana pesanan dibuat, kapan pembayaran dianggap berhasil, bagaimana stok dikurangi, bagaimana pesanan dibatalkan, dan bagaimana proses pengembalian barang dilakukan. DDD membantu tim memodelkan konsep dan aturan tersebut sebagai bagian penting dari domain aplikasi.

Mengapa Domain Driven Design Dibutuhkan?

Aplikasi sederhana biasanya dapat dikembangkan dengan struktur yang relatif mudah. Namun, ketika sistem menangani proses bisnis yang kompleks, jumlah aturan dan hubungan antarfitur dapat berkembang dengan cepat.

Masalah dapat muncul ketika developer hanya berfokus pada aspek teknis tanpa memahami domain bisnis. Nama class, method, dan proses dalam aplikasi mungkin tidak menggunakan istilah yang dipahami oleh tim bisnis. Akibatnya, komunikasi menjadi lebih sulit dan perubahan kebutuhan bisnis dapat membutuhkan perubahan kode yang semakin kompleks.

DDD mencoba mengatasi masalah tersebut dengan menjadikan domain sebagai pusat pemodelan software. Developer dan domain expert bekerja sama untuk memahami proses bisnis, menentukan istilah yang digunakan, kemudian menerjemahkan pemahaman tersebut ke dalam model software.

Dengan demikian, tujuan DDD bukan sekadar membuat struktur kode yang berbeda, tetapi membantu membangun software yang lebih dekat dengan cara bisnis sebenarnya bekerja.

Konsep Dasar Domain Driven Design

DDD memiliki sejumlah konsep penting yang saling berhubungan. Secara umum, konsep tersebut dapat dibagi menjadi dua bagian besar, yaitu Strategic Design dan Tactical Design.

Bagian	Fokus	Contoh Konsep
Strategic Design	Memahami dan membagi domain dalam skala besar	Domain, Subdomain, Bounded Context, Ubiquitous Language, Context Map
Tactical Design	Membentuk model domain di dalam suatu konteks	Entity, Value Object, Aggregate, Repository, Domain Service, Factory, Domain Event

Strategic Design membantu tim menentukan bagaimana domain dibagi dan bagaimana bagian-bagian tersebut berhubungan, sedangkan Tactical Design berfokus pada bagaimana konsep bisnis direpresentasikan di dalam kode.

1. Domain

Dalam DDD, domain adalah area masalah atau bisnis yang ingin diselesaikan oleh software. Domain dapat berupa e-commerce, perbankan, pendidikan, logistik, kesehatan, layanan pelanggan, dan berbagai bidang lainnya.

Misalnya, pada aplikasi marketplace, domain bisnis dapat mencakup proses penjualan produk secara online. Di dalam domain tersebut terdapat berbagai konsep seperti pelanggan, produk, pesanan, pembayaran, pengiriman, dan pengembalian barang.

Memahami domain menjadi langkah penting karena developer perlu mengetahui bukan hanya data apa yang disimpan, tetapi juga aturan dan proses bisnis yang berlaku terhadap data tersebut.

2. Subdomain

Sebuah domain yang besar dapat dibagi menjadi beberapa subdomain berdasarkan bagian atau kemampuan bisnis tertentu. Pembagian ini membantu tim memahami area bisnis secara lebih terstruktur. Sebagai contoh, sebuah platform e-commerce dapat memiliki subdomain seperti:

• Penjualan
• Pembayaran
• Manajemen inventori
• Pengiriman
• Customer service
• Promosi

Tidak semua subdomain memiliki tingkat kepentingan yang sama. Beberapa di antaranya dapat menjadi bagian paling penting yang membedakan bisnis dari kompetitor, sementara bagian lainnya merupakan kemampuan pendukung atau fungsi umum.

Secara konseptual, pembagian subdomain membantu tim menentukan bagian mana yang perlu mendapatkan perhatian terbesar ketika membangun model bisnis.

3. Core Domain

Core Domain adalah bagian domain yang paling penting dan memiliki nilai strategis bagi bisnis. Bagian inilah yang biasanya menjadi fokus utama dalam pengembangan model domain.

Misalnya, perusahaan logistik memiliki algoritma atau aturan khusus untuk menentukan rute pengiriman yang menjadi keunggulan bisnisnya. Kemampuan tersebut dapat menjadi bagian dari core domain karena memiliki pengaruh besar terhadap cara perusahaan menjalankan bisnis.

Core domain tidak selalu berarti fitur yang paling banyak digunakan. Fokusnya lebih kepada bagian bisnis yang memiliki kepentingan strategis dan membutuhkan pemodelan yang benar-benar sesuai dengan kebutuhan organisasi.

4. Supporting Subdomain

Supporting Subdomain adalah bagian bisnis yang tetap diperlukan untuk mendukung operasi utama, tetapi bukan merupakan sumber keunggulan utama perusahaan.

Sebagai contoh, perusahaan e-commerce mungkin memiliki sistem internal untuk mengelola data karyawan. Sistem tersebut penting bagi operasional, tetapi bukan bagian utama yang membedakan layanan e-commerce dari kompetitornya.

Supporting subdomain dapat dikembangkan secara lebih sederhana dibandingkan core domain selama kebutuhan bisnisnya tetap terpenuhi.

5. Generic Subdomain

Generic Subdomain merupakan fungsi yang dibutuhkan oleh bisnis tetapi tidak menjadi keunggulan khusus perusahaan. Fungsi seperti autentikasi, pengiriman email, atau beberapa kemampuan infrastruktur umum dapat termasuk dalam kategori ini, tergantung konteks bisnisnya.

Untuk bagian seperti ini, organisasi dapat mempertimbangkan penggunaan solusi yang sudah tersedia daripada membangun semuanya dari awal. Pembagian antara Core, Supporting, dan Generic Subdomain membantu organisasi menentukan prioritas investasi dalam pengembangan software.

Strategic Design dalam DDD

Strategic Design berfokus pada bagaimana memahami domain secara keseluruhan dan menentukan batas antarbagian sistem. Pendekatan ini sangat berguna ketika aplikasi memiliki banyak proses bisnis atau ketika beberapa tim bekerja pada bagian sistem yang berbeda.

Beberapa konsep penting dalam Strategic Design adalah Ubiquitous Language, Bounded Context, dan Context Map.

1. Ubiquitous Language

Ubiquitous Language adalah bahasa atau istilah bersama yang digunakan oleh developer, domain expert, product team, dan pihak terkait lainnya untuk membicarakan domain bisnis.

Tujuannya adalah mengurangi perbedaan pemahaman mengenai istilah yang digunakan dalam sistem. Bahasa tersebut sebaiknya tercermin dalam percakapan, dokumentasi, desain, dan kode sehingga istilah bisnis tidak berubah menjadi istilah teknis yang memiliki makna berbeda.

Martin Fowler menjelaskan bahwa Ubiquitous Language merupakan bahasa bersama yang dibangun antara developer dan pengguna atau domain expert berdasarkan domain model. Bahasa tersebut juga dapat berkembang seiring meningkatnya pemahaman tim terhadap domain.

Sebagai contoh, jika bisnis menggunakan istilah “Pesanan Dikonfirmasi”, istilah tersebut sebaiknya memiliki arti yang konsisten dalam diskusi bisnis maupun implementasi software. Developer tidak seharusnya menggunakan istilah berbeda yang dapat menimbulkan interpretasi lain.

Ubiquitous Language bukan sekadar daftar istilah. Bahasa tersebut harus dibangun melalui komunikasi dengan orang yang memahami proses bisnis.

2. Bounded Context

Bounded Context adalah batas yang menentukan di mana suatu domain model dan istilah memiliki makna tertentu. Konsep ini menjadi salah satu bagian terpenting dalam DDD karena sebuah sistem besar tidak selalu dapat menggunakan satu model yang sama untuk seluruh bagian bisnis.

Contohnya adalah istilah Customer. Dalam konteks penjualan, Customer mungkin berhubungan dengan proses pembelian. Namun, dalam konteks layanan pelanggan, Customer dapat memiliki informasi dan kebutuhan yang berbeda.

Dengan Bounded Context, setiap bagian sistem dapat memiliki model yang sesuai dengan tanggung jawabnya. Artinya, satu istilah dapat memiliki representasi berbeda pada context yang berbeda tanpa harus memaksakan satu model global.

3. Context Map

Jika sebuah sistem memiliki beberapa Bounded Context, tim perlu memahami bagaimana context tersebut saling berhubungan. Untuk membantu menggambarkan hubungan tersebut, DDD menggunakan konsep Context Map.

Context Map memberikan gambaran mengenai hubungan dan integrasi antar-Bounded Context. Misalnya, context Order dapat berkomunikasi dengan context Payment dan Shipping melalui mekanisme integrasi yang telah ditentukan. Dengan adanya pemetaan tersebut, tim dapat lebih mudah memahami ketergantungan antarbagian sistem dan menentukan bagaimana komunikasi dilakukan.

Tactical Design dalam DDD

Setelah batas domain dan hubungan antarcontext dipahami, tahap berikutnya adalah membangun model domain di dalam Bounded Context. Bagian inilah yang dikenal sebagai Tactical Design. Beberapa building block yang umum digunakan adalah Entity, Value Object, Aggregate, Repository, Domain Service, Factory, dan Domain Event.

1. Entity

Entity adalah objek domain yang memiliki identitas yang membedakannya dari objek lain. Identitas tersebut tetap menjadi pembeda meskipun atribut objek mengalami perubahan.

Contohnya adalah Customer, Order, atau Product. Dua pelanggan dapat memiliki nama yang sama, tetapi keduanya tetap merupakan entitas yang berbeda karena memiliki identitas masing-masing. Entity biasanya memiliki siklus hidup. Status dan atributnya dapat berubah seiring berjalannya proses bisnis, tetapi identitasnya tetap digunakan untuk mengenali entitas tersebut.

2. Value Object

Berbeda dengan Entity, Value Object tidak berfokus pada identitas. Objek ini ditentukan berdasarkan nilai atau atribut yang dimilikinya. Contohnya adalah:

• Alamat
• Nomor telepon
• Mata uang
• Rentang tanggal
• Koordinat
• Nilai uang

Sebagai contoh, dua objek Money dengan mata uang dan nilai yang sama dapat dianggap memiliki nilai yang sama tanpa perlu memiliki identitas unik seperti Entity. Value Object sering digunakan untuk membuat konsep domain lebih eksplisit sekaligus membantu menjaga aturan yang berkaitan dengan nilai tersebut.

3. Aggregate

Aggregate adalah kumpulan objek domain yang diperlakukan sebagai satu unit untuk menjaga konsistensi aturan bisnis tertentu. Aggregate memiliki satu Aggregate Root yang menjadi titik akses utama dari luar aggregate.

Sebagai contoh, dalam sistem pemesanan, sebuah Order dapat menjadi Aggregate Root yang memiliki beberapa Order Item. Perubahan terhadap bagian internal Order dikendalikan melalui root tersebut sehingga aturan bisnis yang berkaitan dengan pesanan dapat dijaga pada batas yang jelas. Aggregate bukan sekadar kumpulan data yang dikelompokkan bersama. Konsep ini terutama digunakan untuk menentukan batas konsistensi dan aturan bisnis dalam model domain.

4. Aggregate Root

Aggregate Root adalah Entity utama yang menjadi pintu masuk untuk mengakses atau mengubah bagian internal sebuah Aggregate.

Misalnya, jika Order merupakan Aggregate Root, perubahan terhadap Order Item dapat dikendalikan melalui Order. Dengan cara tersebut, sistem dapat memastikan aturan bisnis yang berlaku terhadap keseluruhan pesanan tetap terjaga.

Desain Aggregate perlu dilakukan dengan hati-hati. Aggregate yang terlalu besar dapat meningkatkan kompleksitas dan membatasi skalabilitas, sedangkan Aggregate yang terlalu kecil dapat membuat aturan bisnis sulit dijaga dalam satu batas konsistensi.

5. Repository

Repository menyediakan abstraksi untuk mengambil dan menyimpan objek domain tanpa membuat domain model bergantung langsung pada mekanisme penyimpanan tertentu.

Sebagai contoh, OrderRepository dapat menyediakan operasi untuk mencari atau menyimpan Order tanpa membuat logika domain mengetahui apakah data tersebut berasal dari PostgreSQL, MySQL, database NoSQL, atau mekanisme penyimpanan lainnya. Dengan pendekatan tersebut, detail persistence dapat dipisahkan dari logika bisnis. Repository menjadi penghubung antara domain model dan mekanisme penyimpanan.

6. Domain Service

Tidak semua aturan bisnis secara alami cocok ditempatkan di Entity atau Value Object. Jika suatu operasi merupakan bagian penting dari domain tetapi tidak memiliki satu objek yang secara alami bertanggung jawab terhadap operasi tersebut, Domain Service dapat digunakan.

Domain Service biasanya bersifat stateless dan merepresentasikan suatu proses atau aturan bisnis yang melibatkan beberapa konsep domain.

Sebagai contoh, porses tertentu dalam sistem pembayaran yang melibatkan beberapa objek dapat ditempatkan pada Domain Service jika tanggung jawab tersebut tidak secara alami menjadi milik satu Entity.

7. Factory

Factory digunakan untuk menangani proses pembuatan objek domain yang kompleks. Daripada membuat objek dengan proses konstruksi yang panjang di berbagai tempat, pembuatan dapat dipusatkan melalui Factory.

Factory terutama berguna ketika pembuatan sebuah Aggregate atau Entity membutuhkan beberapa aturan dan proses validasi sebelum objek dianggap valid.

8. Domain Event

Domain Event merepresentasikan sesuatu yang penting yang telah terjadi dalam domain bisnis. Contohnya:

• OrderCreated
• PaymentCompleted
• OrderCancelled
• ProductStockUpdated
• ShipmentCreated

Ketika suatu peristiwa penting terjadi, bagian sistem lain dapat merespons peristiwa tersebut tanpa harus terlalu bergantung langsung pada komponen yang menghasilkan event. Domain Event sering digunakan untuk membantu komunikasi antarbagian sistem dan mendukung arsitektur yang lebih longgar keterikatannya.

Perbedaan Strategic Design dan Tactical Design

Kedua pendekatan tersebut memiliki fokus yang berbeda, tetapi saling melengkapi.

Aspek	Strategic Design	Tactical Design
Fokus	Struktur domain secara keseluruhan	Model di dalam Bounded Context
Tujuan	Membagi kompleksitas dan menentukan batas	Mengimplementasikan aturan dan konsep domain
Level	Arsitektur dan desain tingkat tinggi	Desain model dan kode
Contoh	Subdomain, Bounded Context, Context Map	Entity, Value Object, Aggregate, Repository
Pertanyaan utama	“Bagaimana domain dibagi?”	“Bagaimana aturan domain dimodelkan?”

Kesalahan yang cukup umum adalah langsung menggunakan Entity, Repository, atau Aggregate tanpa terlebih dahulu memahami domain dan batas context. Padahal, Tactical Design akan lebih efektif jika keputusan model tersebut didasarkan pada pemahaman domain yang jelas.

Contoh Penerapan DDD pada E-Commerce

Untuk memahami DDD dengan lebih mudah, bayangkan sebuah platform e-commerce yang memiliki berbagai proses bisnis. Sistem tersebut dapat dibagi menjadi beberapa Bounded Context seperti Order, Payment, Inventory, dan Shipping.

Dalam Order Context, sistem berfokus pada pembuatan dan pengelolaan pesanan. Order dapat menjadi Aggregate Root yang mengelola Order Item dan aturan yang berkaitan dengan pesanan. Payment Context memiliki model sendiri untuk menangani pembayaran. Sementara itu, Inventory Context berfokus pada ketersediaan stok dan perubahan jumlah produk.

Ketika pembayaran berhasil, Payment Context dapat menghasilkan Domain Event seperti PaymentCompleted. Order Context kemudian dapat merespons event tersebut sesuai dengan aturan bisnis yang berlaku. Gambaran sederhananya dapat dilihat berikut:

Bounded Context	Fokus Utama	Contoh Konsep
Order	Pengelolaan pesanan	Order, Order Item
Payment	Pemrosesan pembayaran	Payment, Transaction
Inventory	Pengelolaan stok	Product Stock, Warehouse
Shipping	Pengiriman	Shipment, Delivery
Customer	Informasi pelanggan	Customer, Address

Dalam praktiknya, pembagian tersebut tidak harus selalu diterjemahkan menjadi satu microservice untuk setiap context. Bounded Context dan microservice merupakan konsep yang berbeda, meskipun Bounded Context sering menjadi salah satu pertimbangan ketika menentukan batas layanan pada arsitektur terdistribusi.

DDD dan Microservices

DDD sering dikaitkan dengan arsitektur microservices karena konsep Bounded Context dapat membantu tim menentukan batas tanggung jawab suatu layanan. Namun, DDD bukan berarti sama dengan microservices.

DDD berfokus pada pemodelan domain dan kompleksitas bisnis, sedangkan microservices merupakan pendekatan arsitektur untuk membangun sistem sebagai kumpulan layanan yang relatif independen. Dengan demikian, sebuah aplikasi monolith juga dapat menerapkan prinsip DDD. Bounded Context dapat tetap digunakan untuk memisahkan model dan tanggung jawab di dalam satu aplikasi.

DDD	Microservices
Berfokus pada domain bisnis	Berfokus pada arsitektur layanan
Membantu memahami kompleksitas bisnis	Membantu memisahkan aplikasi menjadi layanan
Memiliki konsep Bounded Context	Memiliki service yang dapat berjalan relatif independen
Dapat diterapkan pada monolith	Umumnya digunakan pada sistem terdistribusi
Menekankan domain model	Menekankan deployment dan komunikasi antarservice

Karena itu, menggunakan microservices tanpa memahami domain bisnis belum tentu menghasilkan pembagian layanan yang baik.

Perbedaan DDD vs Pendekatan Database-First

DDD memiliki cara pandang yang berbeda dari pendekatan yang menjadikan database sebagai pusat desain aplikasi. Pada pendekatan database-first, developer biasanya mulai dengan menentukan tabel, kolom, relasi, dan struktur database. Setelah itu, struktur tersebut diterjemahkan menjadi model aplikasi.

Dalam DDD, proses dimulai dengan memahami domain, proses bisnis, istilah, dan aturan yang berlaku. Model domain kemudian menjadi dasar untuk menentukan bagaimana software dibangun dan bagaimana data disimpan.

Aspek	Database-First	Domain-Driven Design
Titik awal	Struktur database	Domain bisnis
Fokus	Data dan relasi	Proses dan aturan bisnis
Model utama	Database model	Domain model
Peran domain expert	Dapat lebih terbatas	Sangat penting
Cocok untuk	Sistem sederhana dan data-centric	Domain dengan aturan bisnis kompleks

Pendekatan database-first tidak selalu salah. Untuk aplikasi dengan kebutuhan bisnis sederhana, pendekatan tersebut dapat menjadi pilihan yang praktis. DDD lebih relevan ketika kompleksitas bisnis menjadi faktor utama dalam desain software.

Kelebihan Domain Driven Design

DDD dapat memberikan sejumlah manfaat, terutama pada proyek dengan domain yang kompleks.

• Lebih Dekat dengan Kebutuhan Bisnis

Model aplikasi dibangun berdasarkan pemahaman terhadap proses dan aturan bisnis. Hal ini membantu memastikan software tidak hanya berfungsi secara teknis, tetapi juga mencerminkan kebutuhan domain.

• Komunikasi Tim Lebih Konsisten

Penggunaan Ubiquitous Language membantu developer dan domain expert menggunakan istilah yang sama. Hal ini dapat mengurangi kesalahpahaman ketika membahas fitur atau aturan bisnis.

• Kompleksitas Lebih Mudah Dipisahkan

Bounded Context membantu membagi domain besar menjadi beberapa model yang memiliki batas dan tanggung jawab lebih jelas.

• Logika Bisnis Lebih Terstruktur

Entity, Value Object, Aggregate, dan Domain Service membantu menempatkan aturan bisnis pada model yang sesuai sehingga logika tidak seluruhnya terkumpul dalam controller atau service yang terlalu besar.

• Lebih Mudah Menghadapi Perubahan Bisnis

Ketika model software benar-benar mencerminkan domain, perubahan aturan bisnis dapat lebih mudah dilacak karena konsep bisnis tersebut memiliki representasi yang jelas di dalam kode.

Kekurangan dan Tantangan DDD

Meskipun menawarkan banyak manfaat, DDD tidak selalu menjadi pilihan yang tepat untuk semua proyek.

• Membutuhkan Pemahaman Domain yang Mendalam

Developer perlu memahami bagaimana bisnis bekerja. Proses ini membutuhkan komunikasi aktif dengan domain expert dan tidak dapat dilakukan hanya dengan membaca struktur database.

• Kurva Belajar Lebih Tinggi

Konsep seperti Aggregate, Bounded Context, Value Object, Domain Event, dan Context Map membutuhkan pemahaman yang cukup sebelum dapat diterapkan secara efektif.

• Bisa Menambah Kompleksitas

Jika diterapkan pada aplikasi sederhana tanpa kebutuhan domain yang kompleks, banyak konsep DDD justru dapat menambah struktur dan kode yang tidak diperlukan.

• Membutuhkan Kolaborasi Lintas Tim

DDD bukan hanya pekerjaan developer. Product manager, business analyst, domain expert, dan pihak terkait lainnya dapat berperan dalam memahami dan memvalidasi domain model.

• Risiko Overengineering

Penggunaan DDD secara berlebihan dapat membuat aplikasi sederhana memiliki terlalu banyak abstraksi. Karena itu, penerapan DDD sebaiknya disesuaikan dengan tingkat kompleksitas domain.

Kapan Sebaiknya Menggunakan DDD?

DDD paling masuk akal ketika kompleksitas bisnis menjadi salah satu tantangan utama dalam pengembangan software. Contohnya adalah sistem perbankan, platform e-commerce berskala besar, sistem logistik, marketplace, asuransi, manufaktur, atau aplikasi enterprise dengan banyak aturan bisnis.

DDD juga dapat membantu ketika banyak tim harus bekerja pada domain yang sama tetapi memiliki tanggung jawab berbeda. Bounded Context dapat digunakan untuk membuat batas model dan tanggung jawab menjadi lebih jelas.

Sebaliknya, untuk website sederhana, blog, landing page, aplikasi CRUD sederhana, atau sistem dengan aturan bisnis yang sangat sedikit, penerapan DDD secara lengkap mungkin tidak memberikan manfaat yang sebanding dengan kompleksitas tambahannya.

Langkah-Langkah Menerapkan Domain Driven Design

Penerapan DDD tidak harus langsung dimulai dengan membuat Entity atau Aggregate. Prosesnya sebaiknya dimulai dengan memahami masalah bisnis.

1. Pahami Domain Bisnis

Pelajari proses bisnis, tujuan sistem, aturan, aktor yang terlibat, dan masalah yang ingin diselesaikan.

2. Identifikasi Istilah Bisnis

Catat istilah yang digunakan oleh domain expert dan pastikan setiap istilah memiliki makna yang jelas.

3. Bangun Ubiquitous Language

Gunakan istilah yang telah disepakati tersebut dalam diskusi, dokumentasi, desain, dan kode.

4. Identifikasi Subdomain

Pisahkan domain menjadi beberapa bagian berdasarkan kemampuan atau area bisnis yang berbeda.

5. Tentukan Bounded Context

Tentukan batas di mana suatu model dan bahasa bisnis memiliki makna tertentu.

6. Buat Context Map

Identifikasi hubungan dan komunikasi antar-Bounded Context.

7. Bentuk Domain Model

Di dalam setiap context, tentukan Entity, Value Object, Aggregate, Domain Service, Repository, dan komponen lain yang memang diperlukan.

8. Validasi Bersama Domain Expert

Domain model perlu dibandingkan kembali dengan proses bisnis sebenarnya. Jika model tidak menggambarkan cara bisnis bekerja, model tersebut perlu diperbaiki.

DDD dan Clean Architecture

DDD juga dapat digunakan bersama pendekatan arsitektur seperti Clean Architecture. Keduanya memiliki fokus yang berbeda.

DDD membantu menentukan dan memodelkan konsep serta aturan bisnis, sedangkan Clean Architecture berfokus pada bagaimana dependency dan struktur aplikasi diatur agar business logic tidak terlalu bergantung pada detail teknis.

Dalam implementasinya, domain model dapat ditempatkan di bagian inti aplikasi, sementara database, framework, API, dan layanan eksternal berada pada bagian luar. Dengan struktur tersebut, aturan bisnis dapat dipisahkan dari detail implementasi.

Namun, DDD tidak mengharuskan penggunaan Clean Architecture. DDD merupakan pendekatan pemodelan domain, sedangkan Clean Architecture merupakan salah satu pendekatan untuk mengorganisasi struktur software.

DDD dan Event-Driven Architecture

Event-Driven Architecture juga dapat dikombinasikan dengan DDD, terutama ketika sistem memiliki beberapa bounded context yang perlu berkomunikasi secara longgar.

Sebagai contoh, ketika pembayaran berhasil, Payment Context dapat menghasilkan event PaymentCompleted. Context lain yang membutuhkan informasi tersebut dapat merespons event tersebut tanpa harus membuat Payment Context mengetahui seluruh proses yang dilakukan oleh context lain.

Pendekatan ini dapat membantu mengurangi coupling, tetapi juga menambah konsekuensi seperti kebutuhan menangani event secara asynchronous, duplikasi event, retry, observability, dan konsistensi data. Karena itu, penggunaan Domain Event atau event-driven architecture sebaiknya didasarkan pada kebutuhan sistem, bukan sekadar karena DDD menggunakannya.

Praktik Terbaik dalam Menerapkan DDD

Agar penerapan DDD tidak berubah menjadi kompleksitas yang tidak diperlukan, beberapa praktik berikut dapat dipertimbangkan.

1. Mulai dari domain, bukan dari database

Pahami proses dan aturan bisnis sebelum menentukan struktur teknis.

2. Gunakan istilah bisnis secara konsisten

Jika sebuah konsep disebut “Order” oleh domain expert, gunakan istilah tersebut secara konsisten dalam dokumentasi dan kode.

3. Jaga Bounded Context tetap jelas

Hindari membuat satu model besar yang digunakan untuk seluruh bagian bisnis ketika setiap bagian sebenarnya memiliki kebutuhan berbeda.

4. Jangan membuat Aggregate terlalu besar

Aggregate sebaiknya memiliki batas tanggung jawab dan konsistensi yang jelas.

5. Gunakan Value Object untuk konsep yang ditentukan oleh nilai

Hal ini dapat membuat domain model lebih ekspresif dan membantu menjaga aturan terkait nilai tersebut.

6. Jangan menerapkan semua pola DDD secara otomatis

Entity, Repository, Factory, Domain Service, dan Domain Event sebaiknya digunakan ketika memang memiliki alasan yang jelas dalam domain.

7. Libatkan domain expert

DDD sangat bergantung pada pemahaman yang benar mengenai bisnis. Developer tidak seharusnya membuat domain model hanya berdasarkan asumsi teknis.

Contoh Sederhana Struktur DDD

Struktur folder dalam proyek DDD dapat berbeda tergantung bahasa pemrograman dan arsitektur yang digunakan. Salah satu pendekatan yang mungkin digunakan adalah memisahkan kode berdasarkan domain atau bounded context. Contohnya:

src/
├── order/
│   ├── domain/
│   │   ├── Order
│   │   ├── OrderItem
│   │   ├── OrderRepository
│   │   └── OrderService
│   ├── application/
│   └── infrastructure/
│
├── payment/
│   ├── domain/
│   ├── application/
│   └── infrastructure/
│
└── inventory/
    ├── domain/
    ├── application/
    └── infrastructure/

Struktur tersebut bukan aturan wajib DDD. Yang lebih penting adalah memastikan struktur kode mencerminkan batas dan tanggung jawab domain secara masuk akal.

Perbedaan DDD dengan OOP, Clean Architecture, dan Microservices

DDD sering dianggap sama dengan beberapa konsep lain dalam software engineering. Padahal, masing-masing memiliki fokus berbeda.

Konsep	Fokus Utama	Hubungan dengan DDD
OOP	Pemodelan software menggunakan object	Dapat digunakan untuk mengimplementasikan domain model
DDD	Pemodelan software berdasarkan domain bisnis	Fokus pada kompleksitas dan aturan bisnis
Clean Architecture	Pemisahan dependency dan struktur aplikasi	Dapat digunakan bersama DDD
Microservices	Arsitektur aplikasi berbasis layanan	Dapat menggunakan Bounded Context sebagai salah satu dasar pembagian layanan
Event-Driven Architecture	Komunikasi melalui event	Dapat digunakan untuk komunikasi antarbagian domain

Dengan memahami perbedaan tersebut, DDD tidak seharusnya dipandang sebagai framework atau teknologi tertentu. DDD lebih tepat dipahami sebagai pendekatan untuk memahami dan memodelkan domain bisnis dalam software.

Kesimpulan

Domain Driven Design (DDD) adalah pendekatan pengembangan software yang menempatkan domain bisnis sebagai pusat dalam proses desain dan pemodelan aplikasi. DDD membantu tim memahami kompleksitas bisnis kemudian menerjemahkannya ke dalam model software menggunakan konsep seperti Ubiquitous Language, Subdomain, Bounded Context, Entity, Value Object, Aggregate, Repository, Domain Service, dan Domain Event.

DDD sangat bermanfaat untuk sistem dengan aturan bisnis yang kompleks karena membantu membuat batas tanggung jawab lebih jelas dan menjaga agar model software tetap dekat dengan kebutuhan bisnis. Namun, DDD bukan solusi yang harus diterapkan pada setiap proyek. Untuk aplikasi sederhana, penerapan seluruh konsep DDD dapat menambah kompleksitas yang sebenarnya tidak diperlukan.

Pada akhirnya, keberhasilan DDD bukan ditentukan oleh seberapa banyak pola yang digunakan, tetapi oleh seberapa baik software mampu merepresentasikan aturan, proses, dan konsep bisnis yang sebenarnya. Karena itu, pemahaman domain dan kolaborasi antara developer dengan domain expert menjadi bagian penting dalam penerapannya.

Untuk mendapatkan informasi lain seputar teknologi, software development, website, hosting, cloud, dan perkembangan teknologi digital, kunjungi Blog Hosteko. Temukan berbagai artikel informatif yang dapat membantu memahami teknologi dan penerapannya dalam kebutuhan digital.