Apa itu Desain Didorong Domain (DDD)? [Tutup]

276

Saya terus melihat DDD (Desain Domain Didorong) banyak digunakan dalam artikel - saya telah membaca entri Wikipedia tentang DDD tetapi masih tidak tahu apa itu sebenarnya dan bagaimana saya akan menerapkannya dalam membuat situs saya?

domain-driven-design

— le3o
sumber

595

Pertama, jika Anda tidak tahu bahwa Anda membutuhkannya, mungkin saja Anda tidak membutuhkannya. Jika Anda tidak mengenali masalah yang dipecahkan DDD maka mungkin Anda tidak memiliki masalah tersebut. Bahkan pendukung DDD akan sering menunjukkan bahwa DDD hanya ditujukan untuk proyek besar (> 6 bulan).

Dengan asumsi bahwa Anda masih membaca pada saat ini, pendapat saya tentang DDD adalah ini:

DDD adalah tentang mencoba menjadikan perangkat lunak Anda model dari sistem atau proses di dunia nyata. Dalam menggunakan DDD, Anda harus bekerja sama dengan pakar domain yang dapat menjelaskan cara kerja sistem dunia nyata. Misalnya, jika Anda mengembangkan sistem yang menangani penempatan taruhan pada pacuan kuda, pakar domain Anda mungkin seorang pembuat taruhan berpengalaman.

Antara diri Anda dan pakar domain, Anda membangun a bahasa di mana mana (UL), yang pada dasarnya merupakan deskripsi konseptual dari sistem. Idenya adalah Anda harus dapat menuliskan apa yang dilakukan sistem dengan cara yang dapat dibaca oleh pakar domain dan memverifikasi bahwa itu benar. Dalam contoh taruhan kami, bahasa di mana-mana akan mencakup definisi kata-kata seperti 'ras', 'taruhan', 'peluang' dan sebagainya.

Konsep-konsep yang dijelaskan oleh UL akan membentuk dasar dari desain berorientasi objek Anda. DDD memberikan beberapa panduan yang jelas tentang bagaimana objek Anda harus berinteraksi, dan membantu Anda membagi objek Anda ke dalam kategori berikut:

Objek nilai, yang mewakili nilai yang mungkin memiliki sub-bagian (misalnya, tanggal mungkin memiliki hari, bulan, dan tahun)
Entitas, yang merupakan objek dengan identitas . Misalnya, setiap objek Pelanggan memiliki identitasnya sendiri, jadi kami tahu bahwa dua pelanggan dengan nama yang sama bukan pelanggan yang sama
Akar agregat adalah objek yang memiliki objek lain. Ini adalah konsep yang kompleks dan bekerja atas dasar bahwa ada beberapa objek yang tidak masuk akal kecuali mereka memiliki pemilik. Misalnya, objek 'Jalur Pesanan' tidak masuk akal tanpa 'Urutan' milik, jadi kami mengatakan bahwa Pesanan adalah akar agregat, dan objek Baris Pesanan hanya dapat dimanipulasi melalui metode di objek Pesanan

DDD juga merekomendasikan beberapa pola:

Gudang , sebuah pola untuk kegigihan (menyimpan dan memuat data Anda, biasanya ke / dari database)
Pabrik , sebuah pola untuk pembuatan objek
Layanan, pola untuk membuat objek yang memanipulasi objek domain utama Anda tanpa menjadi bagian dari domain itu sendiri

Sekarang, pada titik ini saya harus mengatakan bahwa jika Anda belum pernah mendengar hal-hal ini sebelumnya, Anda tidak boleh mencoba menggunakan DDD pada proyek apa pun yang Anda miliki tenggat waktunya. Sebelum mencoba DDD, Anda harus terbiasa dengan pola desain dan pola desain perusahaan . Mengetahui hal ini membuat DDD jauh lebih mudah untuk dipahami. Dan, seperti yang disebutkan di atas, ada pengantar gratis untuk DDD tersedia dari InfoQ (di mana Anda juga dapat menemukan pembicaraan tentang DDD).

— Rob Knight
sumber

Wow ... Jawaban yang bagus! Sangat dihargai dan penjelasan terbaik yang pernah saya baca sejauh satu mil. Terima kasih .. Saya akan mengunduh buku itu besok.

— leen3o

"Akar agregat adalah objek yang memiliki objek lain. Ini adalah konsep yang kompleks dan bekerja atas dasar bahwa ada beberapa objek yang tidak masuk akal kecuali mereka memiliki pemilik." Saya pikir itu mungkin kesalahpahaman di sini, ide yang Anda sebutkan. adalah "Nilai Utuh", sementara Agregat lebih mementingkan Batas Transaksi, di mana semua aturan invarian bisnis perlu ditegakkan di sini.

— super1ha1

Sejujurnya, ini terdengar seperti hampir setiap proyek di mana pengembang berkolaborasi dengan arsitek selama lebih dari sebulan. (Yah, setidaknya menurut pengalaman saya.) Kesadaran yang mana yang membuat saya lebih menghargai jawaban Anda. :)

— Jaroslav Záruba

Saya tidak setuju dengan pernyataan bahwa DDD "hanya ditujukan untuk proyek besar". DDD bukanlah apa-apa yang harus Anda lakukan sepenuhnya atau tidak sama sekali. Anda bisa melakukan beberapa latihan dari DDD. Misalnya Anda hanya bisa melakukan "Nilai Objek" dan "bahasa mana-mana" dan tidak melakukan akar agregat dalam proyek kecil.

— EasterBunnyBugSmasher

Omong-omong, bukankah kita melakukan analisis domain untuk setiap proyek atau model yang kita lakukan. Bukankah kita sudah tidak pernah mengakhiri percakapan sebagai BA dengan pelanggan dan UKM untuk memahami domain dan ruang lingkup proyek? Saya masih tidak mengerti apa yang luar biasa luar biasa dalam DDD maka proyek pengembangan Perangkat Lunak lain di sekitar?

— supernova

Ambil contoh StackOverflow. Alih-alih mulai mendesain beberapa formulir web, Anda lebih berkonsentrasi untuk melakukan pemodelan berorientasi objek dari entitas dalam domain masalah Anda, misalnya Pengguna, Pertanyaan, Jawaban, Suara, Komentar dll. Karena desain didorong oleh detail masalah. domain itu disebut desain berbasis domain .

Anda dapat membaca lebih lanjut di buku Eric Evans .

— Matt Howells
sumber

Ada versi singkat dari buku Eric Evans yang tersedia secara gratis .

— troelskn

Masalahnya adalah Anda membutuhkan seseorang yang memahami domain dengan cara yang cukup rumit sehingga mereka dapat mengatakan sesuatu yang bermanfaat sebelum mereka menggunakan halaman web! Ketika ini terjadi greate!

— Ian Ringrose

Tapi siapa yang akan mulai dengan mendesain formulir, jujur? Setiap kursus akademik yang terhormat akan melalui analisis, desain dan aplikasi pemodelan sesuai dengan persyaratan bisnis. Saya hanya tidak mengerti apa yang baru dengan teknik ini.

— Sebas

Saya juga, ini hanyalah Desain Berorientasi Objek, digunakan oleh semua orang bahkan sebelum konsep ini datang. Saya tidak melihat penemuan baru di sini.

— Ronen Festinger

@RonenFestinger tolong jangan menilai DDD hanya dengan jawaban ini. Ada banyak wawasan dalam buku Eric Evans. Misalnya konteks yang dibatasi. Paradigma Konteks Terbatas adalah salah satu pilar dari layanan-layanan microser yang sedang kita bangun saat ini. Membaca buku juga membantu Anda memahami layanan mikro.

— Kerem Baydoğan