104

Saya melihat istilah ini banyak dalam konteks arsitektur perangkat lunak ("domain-model", "domain-driven-design" dll.). Saya sudah mencarinya di Google, tetapi saya mendapatkan banyak definisi berbeda. Jadi apa itu sebenarnya?

— Sipo
sumber

12

Sayangnya saya pikir itu salah satu kata yang tidak memiliki definisi yang jelas dan sering digunakan dalam konteks yang ambigu. Namun setelah cukup melihatnya, Anda mendapatkan pemahaman. Maksud saya adalah Anda tidak seharusnya berharap untuk memahami penggunaannya bahkan setelah membaca semua jawaban yang akan Anda lihat di sini. Itu akan memakan waktu.

— aaaaaa

15

@aaaaaa persis ... Humpty Dumpty tersenyum menghina. ... "Ketika saya menggunakan sebuah kata," kata Humpty Dumpty, dengan nada yang agak menghina, "itu berarti apa yang saya pilih artinya - tidak lebih dan tidak kurang."

— emory

3

Saya tidak berpikir itu benar bahwa tidak memiliki definisi yang jelas. Jika Anda melihat definisi webster normal, Anda melihat itu adalah "sebuah wilayah di mana kekuasaan dilakukan", "sebuah wilayah yang ditandai secara khas oleh beberapa fitur fisik". Definisi serupa dalam matematika - "domain" dari suatu fungsi. Anda dapat membagi sesuatu yang besar menjadi domain atau wilayah berdasarkan siapa yang bertanggung jawab atas wilayah itu, atau berdasarkan beberapa kriteria. Seperti modul. Jadi 'model domain' (dalam pemahaman saya) adalah model yang dapat Anda gunakan dalam logika bisnis aplikasi Anda . DDD juga ada hubungannya dengan "daerah".

— Sava B.

9

Kata "domain" dalam buku Domain Driven Design karya Eric Evans memiliki makna khusus. Ini tentang perangkat lunak.

Evans melangkah lebih jauh. Dalam pandangannya ada sub domain bahkan dengan perangkat lunak yang sama. Dan ini adalah bagian dari buku yang berhubungan dengan "Desain Strategis".

Ada tiga "domain": domain inti, domain pendukung, dan domain generik. Terkadang dia menyebut ini sebagai sub-domain.

Evans juga sangat peduli tentang bisnis aktual di balik perangkat lunak dan buku ini tidak hanya ditargetkan pada pengembang, tetapi juga arsitek dan manajer yang perlu melihat bagaimana perangkat lunak dan bisnis dapat bekerja sama, dan itulah yang menjadi perhatiannya ketika membahas desain strategis dan sub domain ini.

Jadi, domain inti adalah bagian dari perangkat lunak yang mewakili keunggulan kompetitif dan "raison d'etre" dari perangkat lunak. Itu adalah bagian dari perangkat lunak itu sebabnya pelanggan akan membeli perangkat lunak vs beberapa perangkat lunak lain. Biasanya, Evans melihatnya sebagai domain yang berisi persentase kode terkecil. Anda dapat menganggapnya sebagai 20% yang paling penting. Ini adalah bagian yang Anda tidak dapat benar-benar membeli dari rak dan mungkin hanya satu modul atau komponen dari keseluruhan perangkat lunak.

Domain pendukung masih penting dan bisa unik bagi organisasi tetapi tidak sepenting domain inti. Tanpa itu, perangkat lunak tidak akan begitu berharga dan inti bergantung padanya. Ini bisa berupa beberapa modul dalam perangkat lunak yang telah Anda tulis sendiri dan yang menjalankan fungsi penting namun mendukung inti.

Domain generik adalah yang paling tidak tersesuaikan dan dalam beberapa hal bagian terpenting dari perangkat lunak. Anda mungkin telah menulisnya sendiri tetapi mungkin lebih efisien untuk membelinya di rak atau menggunakan perangkat lunak open source yang terkenal. Bagian dari sistem ini mungkin tidak spesifik untuk domain keseluruhan Anda, jadi misalnya apakah Anda memiliki sistem pengiriman yang merutekan paket atau sistem catatan kesehatan yang mengelola pasien, domain generik adalah bagian dari sistem ini yang umum dan hanya hanya perlu ada di sana untuk berfungsi sama sekali. Ini mungkin merupakan bagian terbesar dari sistem secara keseluruhan, tetapi belum tentu demikian.

Dari perspektif bisnis, penting untuk memutuskan apa domain inti Anda dan memfokuskan sumber daya pengembangan Anda di sana. Evans memiliki banyak video, terutama di situs InfoQ, di mana ia menjelaskan konsep-konsep ini secara lebih rinci.

Jadi sementara kita sering berbicara tentang "domain" dalam perangkat lunak, dalam kasus DDD, itu tidak sesederhana kelihatannya.

Saya harus mencatat bahwa konsep-konsep DDD belum tentu ada dalam komunitas perangkat lunak yang lebih luas. Pengembang, penulis, dan orang-orang produk lainnya mungkin memiliki gagasan dan definisi yang berbeda, beberapa lebih halus dan beberapa kurang. Bahkan penulis lain yang telah menulis tentang DDD mungkin mengabaikan konsep-konsep ini dalam buku Evans, tetapi saya merasa bahwa konsep-konsep itu masih berguna ketika menulis dan merencanakan proyek perangkat lunak.

— RibaldEddie
sumber

1

Re: paragraf terakhir Anda: mungkin kita harus mendapatkan persetujuan tentang domain inti pengembangan perangkat lunak? Tapi, seperti menyetujui apa itu OOP, atau Fungsional atau istilah lain, saya pikir Humpty Dumpty sudah menang sejak lama.

@nocomprende tidak, konsep-konsep ini khusus untuk perangkat lunak individu tertentu dalam organisasi tertentu dalam waktu tertentu. Jadi domain inti untuk MSFT Windows akan berbeda tergantung pada kondisi pasar, harapan pelanggan, dll.

— RibaldEddie

1

Saya kira itu mengingatkan saya pada pepatah lama: "Ada 2 jenis orang: mereka yang membagi orang menjadi dua jenis, dan mereka yang tidak." Tapi ... untuk jenis kedua orang hanya akan ada satu jenis orang ... - kesalahan tipuan tak terbatas - sistem terhenti

@nocomprende maaf saya tidak benar-benar mengerti komentar pertama Anda — bagian dari "menyetujui" pada domain inti pengembangan perangkat lunak adalah lelucon.

— RibaldEddie

109

The domain adalah konteks dunia nyata di mana Anda mencoba untuk memecahkan masalah dengan menggunakan perangkat lunak. Setiap domain dilengkapi dengan keahlian, kosa kata dan alat yang merupakan bagian dari domain itu.

Contoh spesifik domain dapat berupa "permesinan otomatis bagian rumit menggunakan pemotong berputar kecepatan tinggi." Perangkat lunak dan sistem perangkat keras yang melakukan ini disebut pabrik CNC .

Contoh lain dari domain adalah departemen akuntansi di sebuah perusahaan.

Bacaan Lebih Lanjut
Konteks Terbatas oleh Martin Fowler

— Robert Harvey
sumber

4

Ya. Ketika Anda membaca "domain", Anda mungkin dapat mengganti "(dibatasi pada bidang keahlian) tertentu".

— KlaymenDK

1

Hal yang menarik untuk diingat adalah bahwa domain dari perangkat lunak benar-benar tidak ada hubungannya dengan apa yang ingin dicapai manusia, atau apa yang akan mereka pahami. Saya yakin bahwa komputer sederhana di mobil saya melakukan hal-hal untuk mengoptimalkan pembakaran yang saya tidak tahu apa-apa, dan terus terang tidak peduli. Jadi dengan asumsi bahwa perangkat lunak adalah tentang perspektif manusia dan keinginan adalah kesalahpahaman yang sangat berbahaya. Ini mungkin berguna karena sistem perangkat lunak mencakup area yang lebih luas, dengan peningkatan kesadaran dan kemampuan untuk memilih tujuan. Hei, tunggu, bukankah Asimov memikirkan itu, sudah lama sekali?

1

@ user251748 - Ya, saya pikir ini tentang manusia, dan proses yang mereka lakukan, tidak selalu tentang apa yang dipahami orang secara instan.

— Sipo

38

Ini berarti ruang masalah tempat Anda bekerja. Misalnya, jika Anda membangun situs web e-commerce, domain Anda akan menjadi "e-commerce" dan akan melibatkan proses yang terkait dengan praktik penjualan klien / perusahaan Anda. Jadi model domain akan menjadi sesuatu untuk mewakili suatu produk atau faktur atau catatan pengiriman.

— Becuzz
sumber

7

Um, mengingat bahwa situs web domain namesjuga dikenal sebagai domain, saya pikir Anda harus menjelaskan bagaimana Anda menggunakan kata domain di sini.

— YetAnotherRandomUser

@YetAnotherRandomUser - Bagi saya, cukup jelas apa yang dia maksud. ;)

— Sipo

19

Sebuah Domain adalah daerah pengetahuan. Ini bisa dianggap sebagai kegiatan di mana masalah dipecahkan oleh perangkat lunak Anda. ( Wiki , Komunitas DDD )

Eric Evans dalam bukunya, menggunakan pengiriman kargo untuk menjelaskan apa itu DDD. Dalam contohnya, domain adalah segalanya tentang pengiriman . Bagaimana kargo dipindahkan, dikelola, dikirim dan dilacak dll. Ia dilengkapi dengan aturan, bahasa, dan proses spesifiknya sendiri. Mereka akan membuat model domain, objek, layanan, dan sebagainya.

Ketika Anda membuat aplikasi, Anda akan memiliki semacam otorisasi, seperti dunia pengiriman yang sebenarnya, tidak semua orang dapat mengakses gudang. Bagaimana pengguna diotorisasi dan bagaimana izin diberikan dapat berada di luar domain , karena informasi tersebut mungkin tidak relevan dengan pengiriman barang.

Sederhananya: domain adalah tempat Anda berbisnis . Jika bisnis Anda mengirim kargo - kargo pengiriman akan menjadi domain Anda. Jika bisnis Anda dalam mengautentikasi dan mengesahkan personel maka ini akan menjadi domain Anda.

— potfur
sumber

7

Dari Desain Berbasis Domain: Mengatasi Kompleksitas di Jantung Perangkat Lunak , Eric Evans:

Setiap program perangkat lunak berkaitan dengan beberapa aktivitas atau minat penggunanya. Area subjek tempat pengguna menerapkan program adalah domain perangkat lunak.

Domain program pemesanan penerbangan melibatkan orang sungguhan yang naik pesawat sungguhan.

Domain dari program akuntansi adalah uang dan keuangan.

Domain dari sistem kontrol kode sumber adalah pengembangan perangkat lunak itu sendiri.

Model domain, kemudian adalah "abstraksi ketat terorganisir dan selektif" pengetahuan di kepala pakar domain.

Palermo, dalam menggambarkan arsitektur bawang, menawarkan ringkasan ini

Di tengah-tengah kita melihat Model Domain, yang mewakili kombinasi keadaan dan perilaku yang memodelkan kebenaran bagi organisasi.

Fowler, pada gilirannya, menawarkan

Model objek domain yang menggabungkan perilaku dan data.

Jika Anda melihat definisi yang lebih baru, Anda lebih mungkin menemukan referensi bahwa model domain dan model data berbeda . Saya tidak menganggap bahwa perubahan makna begitu banyak sebagai perubahan penekanan - memodelkan perilaku (cara data berubah sebagai respons terhadap informasi dari luar model) memiliki kompleksitas dan variasi yang lebih kaya daripada berbagai cara penulisan berbagai hal. .

— VoiceOfUnasonason
sumber

Saya akan sedikit menyesuaikan definisi Anda dari kegiatan dunia nyata dengan apa yang dilakukan sistem komputer. Misalnya, "Domain sistem kontrol kode sumber adalah" - penyimpanan dan pengambilan file kode sumber . Domain dimodelkan, bukan untuk menangani hal-hal dunia nyata, tetapi untuk membuat sistem pemrograman lebih mudah untuk dibangun dan dipelihara. Jadi penekanannya adalah pada apa yang dapat dilakukan komputer untuk memfasilitasi itu, bukan apa yang dapat dilakukan manusia. Digital X-Rays meningkatkan sensitivitas dan pemrosesan gambar dari proses X-Ray, mereka tidak melakukan apa pun untuk manusia, dan akan sama bermanfaatnya untuk pemindaian bagasi tanpa pengawasan.

2

Karena Anda mungkin sudah memiliki gagasan tentang apa itu domain, saya kira langkah selanjutnya yang akan Anda ambil adalah mencoba mendefinisikan sub-domain, model domain dan, yang lebih penting, konteks yang dibatasi.

Saya mulai dengan menempatkan perspektif domain saya.

Domain

Domain adalah realitas yang kita huni: entitasnya, perilaku mereka, hukum yang mereka patuhi. Itu ada sebelum kita dan akan ada setelah kita, dalam satu atau lain bentuk. Keberadaannya tidak tergantung pada kesadaran kita. Pemasar datang dengan fitur-fitur baru dan melakukan analisis pasar, manajer akun utama berkomunikasi dengan klien, pengembang perangkat lunak mengotomatisasikan proses bisnis. Itu sebabnya domain disebut ruang Masalah.

Sub-domain

DDD mengimplikasikan dekomposisi domain ke dalam sub-domain, untuk memudahkan pemodelan dan pemahamannya. Fakta bahwa Anda menjalankan bisnis menyimpulkan bahwa setidaknya ada satu nilai bisnis yang dominan. Yang Anda hasilkan uang. Yang kami mulai untuk bisnis kami. Jadi, bahkan jika Anda tidak tahu kata seperti itu seperti "Core domain", itu masih ada. Hal yang sama berlaku untuk sub-domain: mungkin Anda akan membutuhkan pembukuan, sumber daya manusia, dukungan teknis - tetapi ini adalah sekunder.

Model domain

Tidak perlu memodelkan sub-domain yang diekstraksi secara keseluruhan. Ada seperangkat aturan tertentu di setiap sub-domain yang kami minati. Aturan yang ditetapkan dalam beberapa sub-domain yang diperlukan untuk mencapai hasil bisnis tertentu disebut model.

Konteks yang dibatasi

Yang paling penting adalah konteks terikat adalah batasan logis.

Ketika kedua sub-domain dan domain inti didefinisikan, saatnya untuk mengimplementasikan kode. Konteks terikat mendefinisikan batas-batas nyata penerapan beberapa sub-domain. Ini adalah area di mana sub-domain tertentu masuk akal, sementara yang lain tidak. Ini dapat berupa ceramah, presentasi, proyek kode dengan batas fisik yang ditentukan oleh artefak.

Apa berikutnya?

Jika Anda tertarik pada bagaimana konsep konteks terbatas berkorelasi dengan konsep subdomain, cara menentukan subdomain dan konteks terbatas, cara merepresentasikan komunikasi mereka satu sama lain dan bagaimana mengatur tim dengan konsep-konsep ini dalam pikiran, mungkin Anda akan tertarik dengan ini bacaan lebih lanjut .

Saya akan mengatakan bahwa domain untuk perangkat lunak adalah apa yang dilakukan perangkat lunak. Tentu saja tidak ada sebelum kita, dan sepenuhnya dibuat oleh kita, untuk melakukan hal-hal yang ingin kita delegasikan sehingga mereka terjadi tanpa interaksi kita. Dengan kata lain, ini tentang mimpi yang kita miliki, yang ingin kita lupakan. Dan, kami dengan cepat lupa bagaimana perangkat lunak itu bekerja segera setelah digunakan. Perangkat lunak adalah permainan yang lebih cocok untuk dipecahkan oleh komputer, kami hanya melakukannya sampai sekarang karena kami belum membangun komputer, untuk menyelesaikan masalah yang tidak ingin diganggu lagi. Tapi, segera ...

Saya tidak membuat diri saya jelas di bagian ini - "sebelum kita", salahku. Saya sama sekali tidak bermaksud bahwa domain itu ada sebelum umat manusia. Yang saya maksud dengan "kami" lebih mirip pengembang perangkat lunak yang memecahkan masalah otomatisasi, katakanlah, proses bisnis dalam e-commerce. Konsep perdagangan rupanya ada sebelum mereka. Jadi, tanggung jawab pengembang adalah memungkinkan untuk mendelegasikan sesuatu ke komputer, seperti yang Anda katakan.

Baik. Maksud saya adalah orang berpikir bahwa sistem komputer adalah cara berurusan dengan dunia nyata. Tetapi komputer membawa banyak ide, persyaratan, dan kekhawatiran yang tidak pernah menjadi bagian dari domain. Ini seperti mengatakan bahwa operasi adalah cara untuk mengatasi masalah emosional. Ya, lobotomi berhasil, tetapi masalah emosional tidak ada hubungannya dengan otak. Dan, perasaan saya sangat dipengaruhi oleh hormon dan neurotransmiter, jadi apakah SSRI merupakan bagian dari biologi, psikologi, hubungan, atau apakah mereka termasuk kategori untuk diri mereka sendiri? Komputer adalah tentang komputer, bukan hal-hal nyata.

1

Komputer adalah tentang pemodelan hal-hal nyata. Hanya area lain di mana hal-hal nyata dapat dilakukan, proses bisnis nyata dapat diimplementasikan, kendala bisnis nyata dapat diterapkan. Katakan, 50 tahun yang lalu saya telah membayar $ 1 ke kasir di toko, sekarang seluruh proses pembelian bisa tanpa interaksi dengan manusia. Namun uang saya yang sebenarnya ditarik dari rekening bank saya yang sebenarnya. Jadi tidak masalah apa yang terlibat dalam proses apa pun, komputer atau manusia atau apa pun. Mungkin ini dapat menarik bagi Anda: medium.com/@wrong.about/…

Uang itu tidak nyata. Proses bisnis tidak nyata. Semua yang bisa kita bicarakan adalah konsep, bukan nyata.

Apa itu domain?

Domain

Sub-domain

Model domain

Konteks yang dibatasi

Apa berikutnya?