Apa itu Desain Berbasis Domain?

Dapatkah seseorang tolong jelaskan (secara ringkas) apa sebenarnya desain yang digerakkan oleh domain? Saya melihat istilah ini cukup banyak tetapi benar-benar tidak mengerti apa itu atau apa yang terlihat. Apa bedanya dengan desain yang digerakkan bukan domain?

Juga, dapatkah seseorang menjelaskan apa Objek Domain itu? Apa perbedaan domain dari objek normal?

EDIT:

Karena ini tampaknya merupakan hasil teratas di Google dan jawaban saya di bawah ini tidak, silakan lihat jawaban yang jauh lebih baik ini:

https://stackoverflow.com/a/1222488/1240557

JAWABAN LAMA (tidak begitu lengkap :))

Untuk membuat perangkat lunak yang baik, Anda harus tahu apa itu perangkat lunak itu. Anda tidak dapat membuat sistem perangkat lunak perbankan kecuali Anda memiliki pemahaman yang baik tentang apa itu perbankan, seseorang harus memahami domain perbankan.

Dari: Desain Didorong Domain oleh Eric Evans.

Buku ini cukup baik dalam menggambarkan DDD.

Daftar untuk mengunduh ringkasan buku , atau mengunduh ringkasan secara langsung .

Domain Driven Design adalah metodologi dan resep proses untuk pengembangan sistem yang kompleks yang fokusnya adalah memetakan kegiatan, tugas, peristiwa, dan data dalam domain masalah ke dalam artefak teknologi dari domain solusi.

Penekanan dari Domain Driven Design adalah untuk memahami domain masalah untuk membuat model abstrak dari domain masalah yang kemudian dapat diimplementasikan dalam serangkaian teknologi tertentu. Desain Domain Driven sebagai metodologi memberikan pedoman untuk bagaimana pengembangan model ini dan pengembangan teknologi dapat menghasilkan sistem yang memenuhi kebutuhan orang-orang yang menggunakannya sementara juga kuat dalam menghadapi perubahan dalam domain masalah.

Sisi proses Desain Domain Driven melibatkan kolaborasi antara pakar domain, orang yang tahu domain masalah, dan pakar desain / arsitektur, orang yang tahu solusi domain. Idenya adalah untuk memiliki model bersama dengan bahasa bersama sehingga ketika orang-orang dari dua domain berbeda ini dengan dua perspektif berbeda mendiskusikan solusi, mereka sebenarnya mendiskusikan basis pengetahuan bersama dengan konsep bersama.

Kurangnya pemahaman domain masalah bersama antara orang-orang yang membutuhkan sistem tertentu dan orang-orang yang merancang dan menerapkan sistem tampaknya menjadi penghalang inti untuk proyek-proyek yang sukses. Desain Berbasis Domain adalah metodologi untuk mengatasi hambatan ini.

Ini lebih dari sekedar memiliki model objek. Fokusnya adalah tentang komunikasi bersama dan peningkatan kolaborasi sehingga kebutuhan aktual dalam domain masalah dapat ditemukan dan solusi yang tepat dibuat untuk memenuhi kebutuhan tersebut.

Desain yang Didorong oleh Domain: Yang Baik dan Menantang memberikan tinjauan singkat dengan komentar ini:

DDD membantu menemukan arsitektur tingkat atas dan menginformasikan tentang mekanisme dan dinamika domain yang perlu direplikasi oleh perangkat lunak. Konkretnya, ini berarti bahwa analisis DDD yang dilakukan dengan baik meminimalkan kesalahpahaman antara para ahli domain dan arsitek perangkat lunak, dan itu mengurangi jumlah permintaan mahal berikutnya untuk perubahan. Dengan memecah kompleksitas domain dalam konteks yang lebih kecil, DDD menghindari memaksa arsitek proyek untuk merancang model objek yang membengkak, yang mana banyak waktu hilang dalam mengerjakan detail implementasi - sebagian karena jumlah entitas yang harus berurusan sering tumbuh melampaui ukuran papan tulis ruang konferensi.

Juga lihat artikel ini Desain Didorong Domain untuk Arsitektur Layanan yang memberikan contoh singkat. Artikel ini menyediakan uraian thumbnail Desain Domain Driven berikut.

Domain Driven Design mendukung pemodelan berdasarkan realitas bisnis yang relevan dengan kasus penggunaan kami. Karena sekarang semakin tua dan tingkat hype menurun, banyak dari kita lupa bahwa pendekatan DDD sangat membantu dalam memahami masalah yang dihadapi dan merancang perangkat lunak menuju pemahaman bersama tentang solusi. Saat membangun aplikasi, DDD berbicara tentang masalah sebagai domain dan subdomain. Ini menggambarkan langkah-langkah / area masalah yang independen sebagai konteks yang dibatasi, menekankan bahasa yang sama untuk membicarakan masalah ini, dan menambahkan banyak konsep teknis, seperti entitas, objek nilai, dan aturan root agregat untuk mendukung implementasi.

Martin Fowler telah menulis sejumlah artikel di mana Desain Domain Driven sebagai metodologi disebutkan. Misalnya artikel ini, BoundedContext , memberikan tinjauan umum tentang konsep konteks terbatas dari Pengembangan Berbasis Domain.

Di masa muda itu kami disarankan untuk membangun model terpadu dari seluruh bisnis, tetapi DDD mengakui bahwa kami telah belajar bahwa "penyatuan total model domain untuk sistem besar tidak akan layak atau hemat biaya" 1 . Jadi alih-alih, DDD membagi sistem besar menjadi Bounded Contexts, yang masing-masingnya dapat memiliki model terpadu - pada dasarnya cara penataan MultipleCanonicalModels.

Anda HANYA BISA memahami desain yang digerakkan oleh Domain dengan terlebih dahulu memahami apa yang berikut ini:

Apa itu domain?

Bidang tempat sistem dibangun. Manajemen bandara, penjualan asuransi, kedai kopi, penerbangan orbital, apa saja.

Bukan hal yang aneh bagi suatu aplikasi untuk menjangkau beberapa domain yang berbeda. Misalnya, sistem ritel daring mungkin berfungsi dalam domain pengiriman (memilih cara pengiriman yang tepat, tergantung pada barang dan tujuan), penetapan harga (termasuk promosi dan penetapan harga khusus pengguna oleh, katakanlah, lokasi), dan rekomendasi (menghitung terkait produk berdasarkan riwayat pembelian).

Apa itu model?

"Perkiraan yang berguna untuk masalah yang dihadapi." - Gerry Sussman

Kelas Karyawan bukan karyawan sungguhan. Ini memodelkan karyawan nyata. Kita tahu bahwa model itu tidak menangkap segala sesuatu tentang karyawan nyata, dan bukan itu intinya. Itu hanya dimaksudkan untuk menangkap apa yang kami minati untuk konteks saat ini.

Domain yang berbeda mungkin tertarik dengan berbagai cara untuk memodelkan hal yang sama. Misalnya, departemen gaji dan departemen sumber daya manusia dapat memodelkan karyawan dengan berbagai cara.

Apa itu model domain?

Model untuk domain.

Apa itu Desain Berbasis Domain (DDD)?

Ini adalah pendekatan pengembangan yang sangat menghargai model domain dan menghubungkannya dengan implementasi. DDD diciptakan dan awalnya dikembangkan oleh Eric Evans.

Diambil dari sini

Berikut ini adalah artikel bagus lainnya yang dapat Anda periksa di Domain Driven Design . jika aplikasi Anda adalah sesuatu yang serius daripada tugas kuliah. Premis dasarnya adalah struktur segala sesuatu di sekitar entitas Anda dan memiliki model domain yang kuat. Bedakan antara layanan yang menyediakan hal-hal terkait infrastruktur (seperti mengirim email, data tetap) dan layanan yang benar-benar melakukan hal-hal yang merupakan persyaratan bisnis inti Anda.

Semoga itu bisa membantu.

Seperti dalam TDD & BDD Anda / tim paling fokus pada pengujian dan perilaku sistem daripada implementasi kode.

Mirip dengan cara ketika analis sistem, pemilik produk, tim pengembangan dan tentu saja kode - entitas / kelas, variabel, fungsi, proses antarmuka pengguna berkomunikasi menggunakan bahasa yang sama, yang disebut Domain Driven Design

DDD adalah proses berpikir. Saat memodelkan desain perangkat lunak, Anda perlu mempertahankan domain / proses bisnis di pusat perhatian daripada struktur data, aliran data, teknologi, dependensi internal dan eksternal.

Ada banyak pendekatan untuk memodelkan systerm menggunakan DDD

• sumber acara (menggunakan acara sebagai satu sumber kebenaran)
• database relasional
• basis data grafik
• menggunakan bahasa fungsional

Objek domain:

Dengan kata-kata yang sangat naif, sebuah objek yang

• memiliki nama berdasarkan proses / aliran bisnis
• memiliki kontrol penuh pada keadaan internalnya yaitu memperlihatkan metode untuk memanipulasi keadaan.
• selalu memenuhi semua invarian bisnis / aturan bisnis dalam konteks penggunaannya.
• mengikuti prinsip tanggung jawab tunggal

DDD (desain berbasis domain) adalah konsep yang berguna untuk menganalisis persyaratan proyek dan menangani kompleksitas persyaratan ini. Sebelum itu orang menganalisis persyaratan ini dengan mempertimbangkan hubungan antara kelas dan tabel dan sebenarnya desain mereka didasarkan pada tabel basis data hubungan itu tidak lama tetapi memiliki beberapa masalah:

• Dalam proyek-proyek besar dengan persyaratan yang kompleks, itu tidak berguna walaupun ini adalah cara desain yang bagus untuk proyek-proyek kecil.

• Ketika Anda berhadapan dengan tidak ada orang teknis yang mereka tidak punya konsep teknis, konflik ini dapat menyebabkan beberapa masalah besar dalam proyek kami.

Jadi DDD menangani masalah pertama dengan mempertimbangkan proyek utama sebagai Domain dan membagi setiap bagian dari proyek ini menjadi potongan-potongan kecil yang kami terkenal dengan Bounded Context dan masing-masing tidak memiliki pengaruh pada bagian lainnya. Dan masalah kedua telah diselesaikan dengan bahasa di mana-mana yang merupakan bahasa umum antara anggota tim teknis dan pemilik Produk yang tidak teknis tetapi memiliki pengetahuan yang cukup tentang persyaratan mereka

Secara umum definisi sederhana untuk Domain adalah proyek utama yang menghasilkan uang bagi pemilik dan tim lain.

Saya percaya pdf berikut akan memberi Anda gambaran yang lebih besar. Desain Didorong Domain oleh Eric Evans

CATATAN: Pikirkan proyek yang dapat Anda kerjakan, terapkan hal-hal kecil yang Anda pahami dan lihat praktik terbaik. Ini akan membantu Anda mengembangkan kemampuan Anda terhadap pendekatan desain arsitektur layanan mikro juga.

Saya tidak ingin mengulangi jawaban orang lain, jadi, singkatnya saya menjelaskan beberapa kesalahpahaman yang umum

• Sumber daya praktis: POLA, PRINSIP, DAN PRAKTEK DESAIN DOMAIN-DRIVEN oleh Scott Millett
• Ini adalah metodologi untuk sistem bisnis yang rumit. Semua masalah teknis dikeluarkan saat berkomunikasi dengan pakar bisnis
• Ini memberikan pemahaman yang luas tentang (model disederhanakan dan suling) bisnis di seluruh tim pengembang.
• itu membuat model bisnis sinkron dengan model kode dengan menggunakan bahasa di mana - mana (bahasa dipahami oleh seluruh tim pengembang, pakar bisnis, analis bisnis, ...), yang digunakan untuk komunikasi dalam tim pengembang atau pengembang dengan tim lain
• Itu tidak ada hubungannya dengan Manajemen Proyek . Meskipun dapat dengan sempurna digunakan dalam metode manajemen proyek seperti Agile.

• Anda harus menghindari menggunakannya di seluruh proyek Anda

  DDD menekankan perlunya memfokuskan upaya paling banyak pada subdomain inti. Subdomain inti adalah area produk Anda yang akan menjadi perbedaan antara itu menjadi sukses dan itu menjadi kegagalan. Ini adalah nilai jual unik produk, alasan produk ini dibuat dan bukan dibeli.

  Pada dasarnya, itu karena terlalu banyak waktu dan usaha. Jadi, disarankan untuk memecah seluruh domain menjadi subdomain dan hanya menerapkannya pada mereka yang memiliki nilai bisnis tinggi. (mis. tidak dalam subdomain umum seperti email, ...)

• Ini bukan pemrograman berorientasi objek. Sebagian besar pendekatan pemecahan masalah dan ( kadang-kadang ) Anda tidak perlu menggunakan pola OO (seperti Gang of Four) dalam model domain Anda. Hanya karena tidak dapat dipahami oleh Pakar Bisnis (mereka tidak tahu banyak tentang Pabrik, Dekorator, ...). Bahkan ada beberapa pola dalam DDD (seperti The Transaction Script, Table Module) yang tidak 100% sejalan dengan konsep OO.