Apakah desain berbasis domain merupakan pola anti-SQL?


44

Saya menyelam di desain berbasis domain (DDD) dan sementara saya masuk lebih dalam di dalamnya ada beberapa hal yang saya tidak dapatkan. Seperti yang saya pahami, poin utama adalah untuk memisahkan Logika Domain (Logika Bisnis) dari Infrastruktur (DB, Sistem File, dll.).

Yang saya bertanya-tanya adalah, apa yang terjadi ketika saya memiliki pertanyaan yang sangat kompleks seperti Permintaan Perhitungan Sumber Daya Material? Dalam kueri semacam itu Anda bekerja dengan operasi set berat, jenis hal yang dirancang untuk SQL. Melakukan perhitungan tersebut di dalam Lapisan Domain dan bekerja dengan banyak set di dalamnya seperti membuang teknologi SQL.

Melakukan perhitungan ini dalam infrastruktur tidak dapat terjadi juga, karena pola DDD memungkinkan untuk perubahan infrastruktur tanpa mengubah Layer Domain dan mengetahui bahwa MongoDB tidak memiliki kemampuan yang sama seperti misalnya SQL Server, yang tidak dapat terjadi.

Apakah itu jebakan dari pola DDD?


34
Sementara SQL dirancang untuk menangani himpunan aljabar relasional, itu bukan hari yang menyenangkan ketika Anda menyadari bahwa setengah dari logika bisnis Anda terkubur dalam beberapa fungsi SQL yang sulit untuk refactor dan bahkan lebih sulit untuk diuji. Jadi, memindahkan ini ke lapisan domain tempat ia bisa bermain dengan teman-temannya terdengar menarik bagi saya. Apakah ini membuang sebagian besar teknologi SQL? Tentu, tetapi SQL jauh lebih mudah untuk dikelola ketika Anda hanya menggunakan SELECT / JOIN.
Jared Goguen

30
@JaredGoguen tetapi ini bisa karena Anda bukan ahli SQL dan bukan karena teknologi
Leonardo Mangano

2
@ JimmyJames apa yang saya coba katakan adalah bahwa jika DDD diimplementasikan dengan baik memungkinkan untuk mengubah lapisan dengan upaya minimum, seperti beralih dari SQL Server ke MongoDB. Tetapi, jika memiliki pertanyaan kompleks dalam SQL, mungkin saya tidak akan dapat beralih ke MongoDB karena perbedaan teknisnya. Saya pikir saya mengatakan hal yang jelas.
Leonardo Mangano

7
... is like throwing away the SQL technologyHanya karena teknologi tertentu dapat melakukan sesuatu tidak berarti itu adalah pilihan terbaik. Ini bukti anekdotal, tetapi saya telah bertemu terlalu banyak bisnis yang dulu menyimpan logika bisnis dalam database dan bermigrasi jauh darinya karena sakit kepala yang dapat dipelihara dalam jangka panjang. Menyederhanakan terlalu banyak, tetapi basis data dimaksudkan untuk menyimpan data dan bahasa pemrograman dimaksudkan untuk mengubah data. Saya tidak ingin menggunakan DB untuk logika bisnis lagi daripada saya ingin mencoba menggunakan aplikasi saya untuk menyimpan data saya secara langsung.
Conor Mancone

8
SQL itu sendiri adalah contoh yang bagus dari DDD. Saat dihadapkan dengan pengorganisasian data terkait, orang terlebih dahulu menentukan bahasa untuk melakukannya: SQL. Implementasi tidak terlalu menjadi masalah. Admin DB tidak perlu tahu C / C ++ untuk menanyakan database. Demikian pula ketika dihadapkan dengan tugas penjadwalan acara seseorang datang dengan sintaks CRON (mhdmw) model domain sederhana yang cocok dengan 99% masalah penjadwalan. Inti dari DDD bukan untuk membuat kelas atau tabel dll. Ini adalah untuk memahami masalah Anda dan membuat sistem untuk bekerja di domain masalah Anda
slebetman

Jawaban:


39

Saat ini, Anda cenderung melihat pembacaan (kueri) ditangani secara berbeda dari penulisan (perintah). Dalam sistem dengan kueri yang rumit, kueri itu sendiri tidak mungkin melewati model domain (yang terutama bertanggung jawab untuk menjaga konsistensi penulisan ).

Anda benar bahwa kami harus memberikan kepada SQL apa yang merupakan SQL. Jadi kami akan merancang model data yang dioptimalkan di sekitar bacaan, dan kueri model data itu biasanya akan mengambil jalur kode yang tidak termasuk model domain (dengan kemungkinan pengecualian dari beberapa validasi input - memastikan bahwa parameter dalam kueri masuk akal).


13
+1 Jawaban yang bagus, tetapi Anda harus memberikan konsep ini nama yang tepat, Segregasi Command-Query.
Mike Mendukung Monica

6
@ Mike Memiliki model yang sangat berbeda untuk membaca dan menulis lebih seperti CQRS daripada CQS.
Andy

3
"Model baca" bukan model domain (atau bagian dari itu)? Saya bukan ahli CQRS, tetapi saya selalu berpikir model perintah sangat berbeda dari model domain klasik, tetapi bukan model baca. Jadi mungkin Anda bisa memberikan contoh untuk ini?
Doc Brown

Butuh waktu terlalu lama bagi saya untuk menyadari bahwa High Performance Mark sedang memanggil kesalahan ketik.
VoiceOfUnreason

@DocBrown - ini adalah usaha saya untuk mengklarifikasi untuk Anda -> cascadefaliure.vocumsineratio.com/2019/04/…
VoiceOfUnreason

21

Seperti yang saya pahami, poin utama adalah untuk memisahkan Logika Domain (Logika Bisnis) dari Infrastruktur (DB, Sistem File, dll.).

Ini adalah dasar dari kesalahpahaman: tujuan DDD bukan untuk memisahkan hal-hal di sepanjang garis keras seperti "ini di server SQL, jadi tidak boleh BL", tujuan DDD adalah untuk memisahkan domain dan menciptakan hambatan antara mereka yang memungkinkan internal suatu domain untuk sepenuhnya terpisah dari internal domain lain, dan untuk mendefinisikan eksternal yang dibagi di antara mereka.

Jangan menganggap "berada di SQL" sebagai penghalang BL / DL — bukan itu masalahnya. Sebaliknya, pikirkan "ini adalah akhir dari domain internal" sebagai penghalang.

Setiap domain harus memiliki API yang menghadap eksternal yang memungkinkannya untuk bekerja dengan semua domain lain : dalam hal lapisan penyimpanan data , itu harus memiliki tindakan baca / tulis (CRUD) untuk objek data yang disimpannya. Ini berarti SQL itu sendiri tidak benar-benar penghalang, VIEWdan PROCEDUREkomponennya. Anda tidak boleh membaca langsung dari tabel: itu adalah detail implementasi yang dikatakan DDD kepada kita bahwa, sebagai konsumen eksternal, kita tidak perlu khawatir.

Pertimbangkan contoh Anda:

Yang saya bertanya-tanya adalah, apa yang terjadi ketika saya memiliki pertanyaan yang sangat kompleks seperti Permintaan Perhitungan Sumber Daya Material? Dalam kueri semacam itu Anda bekerja dengan operasi set berat, jenis hal yang dirancang untuk SQL.

Inilah yang seharusnya ada di SQL, dan itu bukan pelanggaran DDD. Untuk itulah kami membuat DDD . Dengan perhitungan dalam SQL, itu menjadi bagian dari BL / DL. Apa yang akan Anda lakukan adalah menggunakan tampilan terpisah / prosedur tersimpan / apa pun yang Anda miliki, dan menjaga logika bisnis terpisah dari lapisan data, karena itu adalah API eksternal Anda. Bahkan, lapisan data Anda harus menjadi DDD Domain Layer lain, di mana lapisan data Anda memiliki abstraksi sendiri untuk bekerja dengan lapisan domain lainnya.

Melakukan perhitungan ini dalam infrastruktur tidak dapat terjadi juga, karena pola DDD memungkinkan untuk perubahan infrastruktur tanpa mengubah Layer Domain dan mengetahui bahwa MongoDB tidak memiliki kemampuan yang sama seperti misalnya SQL Server, yang tidak dapat terjadi.

Itu kesalahpahaman lain: ia mengatakan detail implementasi secara internal dapat berubah tanpa mengubah lapisan domain lainnya . Tidak dikatakan Anda hanya bisa mengganti seluruh infrastruktur.

Sekali lagi, perlu diingat, DDD adalah tentang menyembunyikan internal dengan API eksternal yang terdefinisi dengan baik. Di mana letak API itu adalah pertanyaan yang sama sekali berbeda, dan DDD tidak mendefinisikannya. Itu hanya mendefinisikan bahwa API ini ada, dan tidak boleh berubah .

DDD tidak diatur untuk memungkinkan Anda mengganti ad-hoc MSSQL dengan MongoDB — keduanya adalah komponen infrastruktur yang sama sekali berbeda.

Sebagai gantinya, mari kita gunakan analogi untuk apa yang didefinisikan oleh DDD: gas vs mobil listrik. Kedua kendaraan memiliki dua metode yang sama sekali berbeda untuk membuat propulsi, tetapi mereka memiliki API yang sama: on / off, throttle / rem, dan roda untuk mendorong kendaraan. DDD mengatakan bahwa kita harus dapat mengganti mesin (gas atau listrik) di mobil kita. Itu tidak mengatakan kita dapat mengganti mobil dengan sepeda motor, dan itulah MSSQL → MongoDB.


1
Terima kasih untuk penjelasannya. Bagi saya adalah topik yang sangat sulit, semua orang memiliki sudut pandang yang berbeda. Satu-satunya hal yang saya tidak setuju adalah perbandingan antara MSSQL (mobil) dan MongoDB (sepeda motor), bagi saya perbandingan yang tepat adalah bahwa ini adalah dua mesin yang berbeda untuk mobil yang sama, tetapi itu hanya pendapat.
Leonardo Mangano

8
@LeonardoMangano Ah, tapi ternyata tidak. MSSQL adalah database relasional, MongoDB adalah database dokumen. Ya, "basis data" menggambarkan keduanya, tetapi sejauh itulah yang terjadi. Teknik baca / tulis sama sekali berbeda. Alih-alih MongoDB, Anda bisa menggunakan Postgre atau MySQL sebagai alternatif, dan itu akan menjadi perbandingan yang valid.
410_Gone

3
"Kamu seharusnya tidak pernah membaca langsung dari meja ..." Kegilaan.
jpmc26

"Anda seharusnya tidak pernah membaca langsung dari tabel ..." Ini adalah aturan yang saya datangi untuk mengimplementasikannya sendiri setelah satu dekade menulis perangkat lunak yang berinteraksi dengan basis data dan menderita melalui kesulitan awal mencoba mengikuti tutorial yang terstruktur di sekitar pola desain yang populer.
Lucifer Sam

@LuciferSam Aye. Itu membuatnya jauh lebih mudah untuk mengelola pemisahan antara detail implementasi, dan batas-batas domain. Satu "objek" di domain mungkin diwakili oleh 5 tabel, jadi kami menggunakan Tampilan untuk merangkum objek itu.
410_Lewat

18

Jika Anda pernah berada di sebuah proyek di mana organisasi yang membayar untuk menjadi tuan rumah aplikasi memutuskan bahwa lisensi lapisan basis data terlalu mahal, Anda akan menghargai kemudahan yang Anda dapat memigrasi penyimpanan database / data Anda. Semua hal dipertimbangkan, sementara ini terjadi, itu tidak sering terjadi .

Anda bisa mendapatkan yang terbaik dari kedua dunia sehingga untuk berbicara. Jika Anda mempertimbangkan melakukan fungsi kompleks dalam basis data sebagai pengoptimalan, maka Anda dapat menggunakan antarmuka untuk menyuntikkan implementasi alternatif perhitungan. Masalahnya adalah Anda harus mempertahankan logika di beberapa lokasi.

Menyimpang dari pola arsitektur

Ketika Anda menemukan diri Anda berselisih dengan menerapkan suatu pola murni, atau menyimpang di beberapa area, maka Anda harus mengambil keputusan. Sebuah pola hanyalah cara templated untuk melakukan sesuatu untuk membantu mengatur proyek Anda. Pada titik ini perlu waktu untuk mengevaluasi:

  • Apakah ini pola yang tepat? (Banyak kali, tapi kadang-kadang itu hanya cocok)
  • Haruskah saya menyimpang dengan cara ini?
  • Sejauh mana saya menyimpang sejauh ini?

Anda akan menemukan bahwa beberapa pola arsitektur cocok untuk 80-90% aplikasi Anda, tetapi tidak terlalu banyak untuk bit yang tersisa. Penyimpangan sesekali dari pola yang ditentukan berguna untuk kinerja atau alasan logistik.

Namun, jika Anda menemukan bahwa penyimpangan kumulatif Anda berjumlah lebih dari 20% dari arsitektur aplikasi Anda, itu mungkin hanya cocok.

Jika Anda memilih untuk terus menggunakan arsitektur, maka bantulah diri Anda sendiri dan dokumentasikan di mana dan mengapa Anda menyimpang dari cara yang ditentukan dalam melakukan sesuatu. Ketika Anda mendapatkan anggota baru yang antusias di tim Anda, Anda dapat mengarahkan mereka ke dokumentasi yang mencakup pengukuran kinerja, dan justifikasi. Itu akan mengurangi kemungkinan permintaan ulang untuk memperbaiki "masalah". Dokumentasi itu juga akan membantu melemahkan penyimpangan yang merajalela.


Saya akan menghindari penggunaan frasa seperti "apakah ini pola yang tepat" dalam jawaban. Cukup sulit untuk membuat orang menjadi spesifik ketika mereka menulis pertanyaan mereka, dan dengan pengakuan Anda sendiri "kadang-kadang itu tidak cocok," yang menunjukkan bahwa tidak, itu bukan pola yang tepat.
Robert Harvey

@ RobertTarvey, saya pernah berada di proyek di mana pola yang digunakan tidak tepat untuk aplikasi, yang menyebabkannya gagal metrik kualitas tertentu. Ini tentu saja bukan norma, tetapi ketika itu terjadi, Anda memiliki keputusan yang sulit untuk mengubah arsitektur atau menyimpan kode sepatu di dalam aplikasi. Semakin cepat Anda dapat menentukan kecocokan buruk, semakin mudah untuk memperbaikinya. Itu sebabnya saya selalu memasukkan pemikiran itu saat mengevaluasi kasus tepi. Seiring dengan peluru terakhir, kadang-kadang Anda tidak menyadari betapa buruknya itu sampai Anda melihat akumulasi penyimpangan.
Berin Loritsch

7

Set manipulasi logika yang baik di SQL dapat diintegrasikan dengan DDD tidak ada masalah.

Katakan misalnya saya perlu tahu beberapa nilai agregat, jumlah total produk berdasarkan jenis. Mudah dijalankan dalam sql, tetapi lambat jika saya memuat setiap produk ke dalam memori dan menambahkan semuanya.

Saya cukup memperkenalkan objek Domain baru,

ProductInventory
{
    ProductType
    TotalCount
    DateTimeTaken
}

dan metode di repositori saya

ProductRepository
{
    List<ProductInventory> TakeInventory(DateTime asOfDate) {...}
}

Tentu, mungkin sekarang saya mengandalkan DB saya memiliki kemampuan tertentu. Tetapi saya masih memiliki pemisahan secara teknis dan selama logikanya sederhana, saya dapat berargumen bahwa itu bukan 'logika bisnis'


Yah, sejauh ini saya ingat. Repositori juga seharusnya menjadi Queryparameter. repository.find(query);. Saya telah membaca yang sama tetapi dengan Specs. That opens a door to leave Query` sebagai abstraksi dan QueryImplatau implementasi spesifik-permintaan ke lapisan infrastruktur.
Laiv

5
oh tuhan, aku tahu beberapa orang melakukan itu tapi kupikir itu mengerikan. Anda dapat melihat hal semacam ini sebagai langkah di jalan itu. Tapi saya pikir itu bisa diambil dengan hati-hati.
Ewan

I know some people do thatbeberapa orang sangat penting dan kerangka kerjanya. SpringFramework memiliki banyak hal ini :-). Bagaimanapun, Seperti @VoiceOfUnreason telah menyarankan, kunci di sekitar DDD adalah menjaga konsistensi tulisan. Saya tidak yakin tentang pemaksaan desain dengan model domain yang hanya tujuan kueri atau parametrizing queries. Itu bisa didekati dari domain dengan struktur data (pocos, pojos, dtos, pembuat pemetaan baris, apa pun).
Laiv

jelas kami membutuhkan semacam permintaan untuk membantu orang-orang kembali ke kewarasan. Tapi saya tetap berpegang pada senjata saya. Paparan sebagian datalayer dapat diterima ketika secara objektif membuat aplikasi yang lebih baik, di mana "Objek Domain" apa yang subjektif atau tidak
Ewan

1
@LeonardoMangano tergantung pada aplikasi dan implementasi Anda. Hal utama yang harus disadari adalah bahwa Anda dapat menafsirkan kembali Domain Anda untuk membuatnya praktis.
Ewan

3

Salah satu cara yang mungkin untuk menyelesaikan dilema ini adalah dengan memikirkan SQL sebagai bahasa rakitan: Anda jarang, jika sama sekali, kode langsung di dalamnya, tetapi di mana kinerja penting, Anda harus dapat memahami kode yang dihasilkan oleh C Anda. / C ++ / Golang / Rust compiler dan mungkin bahkan menulis snippet kecil di assembly, jika Anda tidak dapat mengubah kode dalam bahasa tingkat tinggi Anda untuk menghasilkan kode mesin yang diinginkan.

Demikian pula, dalam bidang basis data dan SQL, berbagai pustaka SQL (beberapa di antaranya adalah ORM ), misalnya SQLAlchemy dan Django ORM untuk Python, LINQ untuk .NET, memberikan abstraksi tingkat yang lebih tinggi namun menggunakan kode SQL yang dihasilkan di mana memungkinkan untuk mencapai kinerja. Mereka juga menyediakan portabilitas untuk DB yang digunakan, mungkin memiliki kinerja yang berbeda, misalnya pada Postgres dan MySQL, karena beberapa operasi menggunakan beberapa SQL spesifik DB yang lebih optimal.

Dan seperti halnya bahasa tingkat tinggi, sangat penting untuk memahami cara kerja SQL, bahkan jika itu hanya untuk mengatur ulang pertanyaan yang dilakukan dengan pustaka SQL yang disebutkan di atas, untuk dapat mencapai efisiensi yang diinginkan.

PS Saya lebih suka berkomentar tapi saya tidak punya reputasi yang cukup untuk itu.


2

Seperti biasa, ini adalah salah satu hal yang tergantung pada sejumlah faktor. Memang benar bahwa ada banyak yang dapat Anda lakukan dengan SQL. Ada juga tantangan dengan menggunakannya dan beberapa keterbatasan praktis dari basis data relasional.

Seperti yang dicatat Jared Goguen dalam komentar, SQL bisa sangat sulit untuk diuji dan diverifikasi. Faktor utama yang menyebabkan hal ini adalah bahwa ia tidak dapat (secara umum) diuraikan menjadi komponen-komponen. Dalam praktiknya, kueri yang kompleks harus dipertimbangkan dalam toto. Faktor rumit lainnya adalah perilaku dan kebenaran SQL sangat tergantung pada struktur dan konten data Anda. Ini berarti bahwa pengujian semua skenario yang mungkin (atau bahkan menentukan apa skenario itu) seringkali tidak layak atau tidak mungkin. Refactoring SQL dan modifikasi struktur database juga bermasalah.

Faktor besar lainnya yang menyebabkan pindah dari SQL adalah database relasional cenderung hanya skala secara vertikal. Sebagai contoh, ketika Anda membangun perhitungan kompleks dalam SQL untuk dijalankan di SQL Server, mereka akan mengeksekusi pada database. Itu berarti semua pekerjaan itu menggunakan sumber daya pada database. Semakin banyak yang Anda lakukan dalam SQL, semakin banyak sumber daya yang dibutuhkan oleh database Anda baik dari segi memori maupun CPU. Seringkali kurang efisien untuk melakukan hal-hal ini pada sistem lain, tetapi tidak ada batasan praktis untuk jumlah mesin tambahan yang dapat Anda tambahkan ke solusi seperti itu. Pendekatan ini lebih murah dan lebih toleran daripada membangun server database monster.

Masalah-masalah ini mungkin atau mungkin tidak berlaku untuk masalah yang dihadapi. Jika Anda dapat memecahkan masalah Anda dengan sumber daya database yang tersedia, mungkin SQL baik untuk ruang masalah Anda. Namun, Anda perlu mempertimbangkan pertumbuhan. Mungkin baik-baik saja hari ini tetapi beberapa tahun ke depan, biaya penambahan sumber daya mungkin menjadi masalah.


Bukankah alternatif untuk database monster, hanya sejumlah mengerikan dan keragaman sistem tambahan? Ketahanan apa yang dimiliki sistem bantu, jika semuanya menggantung dari sistem inti? Dan jika pembenaran hanyalah keterbatasan teknologi dari sistem inti, maka ini akan sering menjadi optimasi prematur untuk sebagian besar sistem bisnis. SQL secara umum dapat ditulis dengan cara yang dipisahkan, jika dianggap perlu.
Steve

@ Sveve Saya pikir di mana Anda salah di sini dengan asumsi harus ada sistem inti tunggal yang 'hang' dari orang lain.
JimmyJames

@Steve Untuk memberikan contoh, Anda dapat mengganti seluruh sistem basis data dengan database no-SQL tunggal (saya tidak mengatakan ini selalu pilihan yang tepat, hanya saja itu bisa dilakukan.) Basis data itu kemudian dapat disimpan di banyak sistem, bahkan wilayah geografis. DB semacam itu bukan tambahan, ini adalah penggantian grosir dari SQL DB.
JimmyJames

@ JimmyJames, setuju, tetapi ketika tidak ada sistem inti, itu dapat membuat masalah sendiri menganalisis dependensi dan menjaga konsistensi data. Itulah alasan mengapa monolit - mereka menciptakan semacam kesederhanaan tertentu, dan karena itu beberapa jenis analisis dan efisiensi pemeliharaan. Solusi non-monolitik hanya menukar beberapa masalah atau biaya dengan yang lain.
Steve

@jmoreno Melemparkan sumber daya pada sesuatu untuk tertatih-tatih dengannya bukanlah apa yang saya sebut rekayasa yang baik: "untuk menangani volume data situs yang besar, dan menjalankan 9.000 contoh memcached untuk mengimbangi jumlah transaksi database harus dilayani. " Apakah Anda mempertimbangkan biaya desain Anda atau apakah Anda menganggap seseorang akan mengeluarkan uang untuk membuat preferensi pribadi Anda bisa diterapkan?
JimmyJames

2

Apakah itu jebakan dari pola DDD?

Biarkan saya membersihkan beberapa kesalahpahaman.

DDD bukan sebuah pola. Dan itu tidak benar-benar menentukan pola.

Kata pengantar buku DDD Eric Evan menyatakan:

Perancang perangkat lunak terkemuka telah mengakui pemodelan domain dan desain sebagai topik penting selama setidaknya 20 tahun, namun yang mengejutkan hanya sedikit yang ditulis tentang apa yang perlu dilakukan atau bagaimana melakukannya. Meskipun tidak pernah dirumuskan dengan jelas, sebuah filsafat telah muncul sebagai arus bawah dalam komunitas objek, sebuah filosofi yang saya sebut desain yang digerakkan oleh domain.

[...]

Fitur umum untuk keberhasilan adalah model domain kaya yang berevolusi melalui iterasi desain dan menjadi bagian dari struktur proyek.

Buku ini menyediakan kerangka kerja untuk membuat keputusan desain dan kosakata teknis untuk membahas desain domain. Ini adalah sintesis dari praktik terbaik yang diterima secara luas bersama dengan wawasan dan pengalaman saya sendiri.

Jadi, ini adalah cara untuk mendekati pengembangan perangkat lunak dan pemodelan domain, ditambah beberapa kosakata teknis yang mendukung kegiatan tersebut (kosakata yang mencakup berbagai konsep dan pola). Itu juga bukan sesuatu yang sepenuhnya baru.

Hal lain yang perlu diingat adalah bahwa model domain bukan implementasi OO yang dapat ditemukan di sistem Anda - itu hanya satu cara untuk mengekspresikannya, atau untuk mengekspresikan beberapa bagian dari itu. Model domain adalah cara Anda berpikir tentang masalah yang Anda coba selesaikan dengan perangkat lunak. Begitulah cara Anda memahami dan memahami berbagai hal, bagaimana Anda membicarakannya. Itu konseptual . Tapi tidak dalam arti yang kabur. Ini dalam dan halus, dan merupakan hasil kerja keras dan pengumpulan pengetahuan. Lebih lanjut disempurnakan dan kemungkinan berkembang dari waktu ke waktu, dan itu melibatkan pertimbangan implementasi (beberapa di antaranya dapat menghambat model). Itu harus dibagikan oleh semua anggota tim (dan melibatkan ahli domain), dan itu harus mengarahkan bagaimana Anda menerapkan sistem, sehingga sistem mencerminkannya dengan cermat.

Tidak ada yang secara inheren pro atau anti-SQL, meskipun pengembang OO mungkin umumnya lebih baik dalam mengekspresikan model dalam bahasa OO, dan ekspresi banyak konsep domain lebih baik didukung oleh OOP. Tetapi kadang-kadang bagian dari model harus diekspresikan dalam paradigma yang berbeda.

Apa yang saya pikirkan adalah, apa yang terjadi ketika saya memiliki pertanyaan yang sangat kompleks?

Nah, secara umum ada dua skenario di sini.

Dalam kasus pertama, beberapa aspek dari suatu domain benar-benar membutuhkan kueri yang kompleks, dan mungkin aspek tersebut paling baik diungkapkan dalam paradigma SQL / relasional - jadi gunakan alat yang sesuai untuk pekerjaan itu. Cerminkan aspek-aspek tersebut dalam pemikiran domain Anda dan bahasa yang digunakan dalam mengkomunikasikan konsep. Jika domainnya kompleks, mungkin ini adalah bagian dari subdomain dengan konteks terikatnya sendiri.

Skenario lain adalah bahwa kebutuhan yang dirasakan untuk mengekspresikan sesuatu dalam SQL adalah hasil dari pemikiran yang terbatas. Jika seseorang atau tim selalu berorientasi pada basis data dalam pemikiran mereka, mungkin sulit bagi mereka, hanya karena inersia, untuk melihat cara berbeda dalam mendekati sesuatu. Ini menjadi masalah ketika cara lama gagal memenuhi kebutuhan baru, dan membutuhkan beberapa pemikiran di luar kotak. DDD, sebagai pendekatan untuk desain, sebagian tentang cara untuk menemukan jalan keluar dari kotak itu dengan mengumpulkan dan menyaring pengetahuan tentang domain. Tetapi semua orang tampaknya mengabaikan bagian buku itu, dan berfokus pada beberapa kosa kata dan pola teknis yang tercantum.


0

Sekuel menjadi populer ketika memori mahal, karena model data relasional memberikan kemungkinan untuk menormalkan data Anda dan secara efektif menyimpannya dalam sistem file.

Sekarang memori relatif murah, sehingga kita dapat melewati normalisasi dan menyimpan dalam format yang kita gunakan atau bahkan menduplikasi banyak data yang sama demi kecepatan.

Pertimbangkan database sebagai perangkat IO sederhana , yang bertanggung jawab untuk menyimpan data dalam sistem file - ya saya tahu sulit membayangkannya, karena kami menulis banyak aplikasi dengan logika bisnis penting yang ditulis ke dalam query SQL - tetapi coba bayangkan SQL Server itu hanyalah printer lain.

Apakah Anda menanamkan generator PDF ke driver printer atau menambahkan pemicu yang akan mencetak halaman log untuk setiap pesanan penjualan yang dicetak dari printer kami?

Saya berasumsi jawabannya tidak, karena kami tidak ingin aplikasi kami digabungkan ke jenis perangkat tertentu (bahkan tidak berbicara tentang efisiensi ide semacam itu)

Dalam 70-an -90-an database SQL efisien, sekarang? - Tidak yakin, dalam beberapa skenario, kueri data asinkron akan mengembalikan data yang diperlukan lebih cepat dari beberapa gabungan dalam kueri SQL.

SQL tidak dirancang untuk kueri yang rumit, ia dirancang untuk menyimpan data dengan cara yang efisien dan kemudian menyediakan antarmuka / bahasa untuk permintaan data yang disimpan.

Saya akan mengatakan membangun aplikasi Anda di sekitar model data relasional dengan pertanyaan rumit adalah penyalahgunaan mesin basis data. Tentu saja penyedia mesin basis data senang ketika Anda menggabungkan bisnis Anda dengan produk mereka - mereka akan sangat senang untuk memberikan lebih banyak fitur yang membuat ikatan ini semakin kuat.


1
Tapi saya terus berpikir bahwa SQL lebih baik untuk mengatur perhitungan daripada bahasa lain. Dari sudut pandang saya. contoh Anda terbalik, menggunakan C # untuk operasi set yang sangat kompleks dengan jutaan baris dan gabungan yang terlibat menggunakan alat yang salah, tetapi saya bisa saja salah.
Leonardo Mangano

@LeonardoMangano, beberapa contoh: dengan c # Saya dapat memotong jutaan baris dan menghitungnya secara paralel, saya dapat mengambil data secara tidak sinkron dan menjalankan perhitungan "dalam waktu" ketika data dikembalikan, dengan c # Saya dapat melakukan perhitungan dengan penggunaan memori yang rendah dengan menghitung baris demi baris. Memiliki logika yang kompleks dalam kode akan memberi Anda banyak pilihan cara melakukan perhitungan.
Fabio
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.