Saya menyelami konsep-konsep Desain Domain-Driven (DDD) dan menemukan beberapa prinsip aneh, terutama mengenai isolasi domain dan model ketekunan. Inilah pemahaman dasar saya:
- Layanan pada lapisan aplikasi (menyediakan serangkaian fitur) meminta objek domain dari repositori yang diperlukan untuk menjalankan fungsinya.
- Implementasi konkret dari repositori ini mengambil data dari penyimpanan yang diimplementasikan untuknya
- Layanan memberi tahu objek domain, yang merangkum logika bisnis, untuk melakukan tugas-tugas tertentu yang mengubah keadaannya.
- Layanan memberi tahu repositori untuk tetap mempertahankan objek domain yang dimodifikasi.
- Repositori perlu memetakan objek domain kembali ke representasi terkait dalam penyimpanan.
Sekarang, dengan asumsi di atas, yang berikut ini tampak canggung:
Iklan 2 .:
Model domain tampaknya memuat seluruh objek domain (termasuk semua bidang dan referensi), bahkan jika mereka tidak diperlukan untuk fungsi yang memintanya. Memuat seluruhnya mungkin bahkan tidak mungkin jika objek domain lain direferensikan, kecuali jika Anda memuat objek domain tersebut juga dan semua objek yang dirujuk secara bergantian, dan seterusnya dan seterusnya. Pemuatan malas muncul di pikiran, yang berarti bahwa Anda mulai menanyakan objek domain Anda yang seharusnya menjadi tanggung jawab repositori.
Mengingat masalah ini, cara "benar" memuat objek domain tampaknya memiliki fungsi pemuatan khusus untuk setiap kasus penggunaan. Fungsi-fungsi khusus ini hanya akan memuat data yang diperlukan oleh use case mereka dirancang untuk. Di sinilah kejanggalan berperan: Pertama, saya harus mempertahankan sejumlah besar fungsi pemuatan untuk setiap implementasi repositori, dan objek domain akan berakhir di keadaan tidak lengkap yang dibawa null
di bidangnya. Yang terakhir seharusnya secara teknis tidak menjadi masalah karena jika suatu nilai tidak dimuat, itu seharusnya tidak diperlukan oleh fungsi yang memintanya. Masih canggung dan potensi bahaya.
Iklan 3 .:
Bagaimana objek domain memverifikasi keunikan kendala pada konstruksi jika tidak memiliki gagasan tentang repositori? Misalnya, jika saya ingin membuat yang baru User
dengan nomor jaminan sosial yang unik (yang diberikan), konflik paling awal akan terjadi setelah meminta repositori untuk menyimpan objek, hanya jika ada batasan keunikan yang ditentukan pada database. Kalau tidak, saya bisa mencari User
dengan jaminan sosial yang diberikan dan melaporkan kesalahan jika ada, sebelum membuat yang baru. Tapi kemudian cek kendala akan tinggal di layanan dan bukan di objek domain tempat mereka berada. Saya baru menyadari bahwa objek domain sangat diperbolehkan menggunakan repositori (disuntikkan) untuk validasi.
Iklan 5 .:
Saya melihat pemetaan objek domain ke backend penyimpanan sebagai proses yang padat karya dibandingkan dengan objek domain yang memodifikasi data yang mendasari secara langsung. Tentu saja, ini merupakan prasyarat penting untuk memisahkan implementasi penyimpanan konkret dari kode domain. Namun, apakah ini memang mahal?
Anda tampaknya memiliki opsi untuk menggunakan alat ORM untuk melakukan pemetaan untuk Anda. Ini sering mengharuskan Anda untuk merancang model domain sesuai dengan batasan ORM, namun, atau bahkan memperkenalkan ketergantungan dari domain ke lapisan infrastruktur (misalnya, dengan menggunakan anotasi ORM dalam objek domain). Saya juga pernah membaca bahwa ORM memperkenalkan overhead komputasi yang cukup besar.
Dalam kasus database NoSQL, yang hampir tidak ada konsep seperti ORM, bagaimana Anda melacak properti yang diubah dalam model domain save()
?
Sunting : Juga, agar repositori dapat mengakses keadaan objek domain (yaitu nilai dari setiap bidang), objek domain perlu mengungkapkan status internalnya yang memecah enkapsulasi.
Secara umum:
- Ke mana logika transaksional pergi? Ini tentu saja merupakan kegigihan yang spesifik. Beberapa infrastruktur penyimpanan mungkin bahkan tidak mendukung transaksi sama sekali (seperti repositori tiruan dalam memori).
- Untuk operasi massal yang memodifikasi banyak objek, apakah saya harus memuat, memodifikasi, dan menyimpan setiap objek secara terpisah untuk dapat melalui logika validasi yang dienkapsulasi objek? Itu bertentangan dengan mengeksekusi permintaan tunggal langsung ke database.
Saya akan sangat menghargai beberapa klarifikasi tentang topik ini. Apakah asumsi saya benar? Jika tidak, apa cara yang benar untuk mengatasi masalah ini?