Dalam DDD, apakah logika aplikasi validasi, atau logika domain?

Misalkan kita memodelkan formulir menggunakan DDD; formulir tersebut mungkin memiliki beberapa jenis aturan bisnis yang terkait dengannya - mungkin Anda perlu menentukan penghasilan jika Anda bukan pelajar, dan Anda diharuskan untuk mendaftarkan anak-anak Anda jika Anda mengindikasikan bahwa Anda sudah menikah. Dan jika Anda menentukan suatu negara, maka itu harus memiliki negara yang valid.

Apakah validasi semacam ini hidup di domain atau lapisan aplikasi? Beberapa masalah lain yang saya pertimbangkan:

• Kerangka kerja tertentu, seperti Laravel, memberikan aturan validasi yang dapat memvalidasi input sebelum permintaan menyentuh controller. Apakah itu merusak DDD jika validasi dilakukan pada level itu?

• Untuk kasus seperti menentukan apakah negara itu valid, biasanya saya hanya akan meminta tabel database dari semua negara di dunia. Namun, dalam DDD, ini kemungkinan (dari pemahaman saya) dilakukan pada lapisan domain. Apakah lapisan domain diizinkan untuk mengakses DB, atau haruskah saya menggunakan pencarian non-SQL untuk menentukan negara yang valid?

• Apakah perlu untuk memvalidasi input pada aplikasi, dan lapisan domain?

Apakah validasi semacam ini hidup di domain atau lapisan aplikasi?

Aplikasi. Istilah pencarian ajaib yang Anda inginkan adalah lapisan anti korupsi

Biasanya, pesan yang diterima oleh aplikasi Anda akan terasa seperti DTO. Lapisan anti korupsi Anda biasanya akan membuat tipe nilai yang akan dikenali domain. Perintah aktual yang dikirim ke model domain akan diekspresikan dalam bentuk tipe nilai yang divalidasi.

Contoh: perintah DepositMoney kemungkinan akan mencakup jumlah, dan jenis mata uang. Representasi DTO mungkin akan menyatakan jumlah sebagai bilangan bulat, dan kode mata uang sebagai string. Lapisan anti korupsi akan mengubah DTO menjadi tipe nilai Deposit, yang akan mencakup Jumlah yang divalidasi (yang harus tidak negatif) dan CurrencyCode yang divalidasi (yang harus menjadi salah satu kode yang didukung dalam domain).

Setelah berhasil mem-parsing perintah ke dalam tipe-tipe yang dimengerti model domain, perintah dieksekusi dalam domain, yang mungkin masih menolak perintah dengan alasan bahwa itu akan melanggar invarian bisnis (akun belum ada, akun diblokir, akun khusus ini tidak diizinkan untuk menggunakan mata uang itu? dll).

Dengan kata lain, validasi bisnis akan terjadi dalam model domain, setelah lapisan anti korupsi memvalidasi input.

Implementasi aturan validasi biasanya akan hidup di konstruktor dari tipe nilai, atau dalam metode pabrik yang digunakan untuk membangun tipe nilai. Pada dasarnya, Anda membatasi konstruksi objek sehingga dijamin valid, mengisolasi logika di satu tempat, dan menjalankannya pada batas proses.

Model domain masalah Anda mencakup aturan bisnis domain Anda. Aturan bisnis adalah kendala pada elemen model. Itu berarti bahwa lift tidak bergerak dengan pintu terbuka, bahwa barang yang mudah rusak tidak dimuat ke wadah yang tidak didinginkan, dan bahwa pesanan yang dibatalkan tidak dikirimkan.

Itu tidak berarti bahwa ketika domain Anda berinteraksi dengan manusia (melalui layar, formulir, dll.) Maka tidak perlu ada validasi atau bantuan. Sadarilah itu opsional.

Pertimbangkan bahwa ada dua jenis aturan bisnis: - aturan properti yang membatasi atribut suatu objek, dan aturan kolaborasi yang membatasi penambahan dan penghapusan kolaborasi antar objek.

Aturan bisnis berbeda dari aturan logika, yang terkait dengan bahasa pemrograman Anda dan memeriksa bahwa nilai telah diberikan dan tidak nol, dll.

Catatan: tidak ada konsep dalam DDD tentang "pemodelan" formulir Anda.

Apakah keadaan tertentu membuat entitas model tidak valid? Jika ya, maka model tersebut harus mencegah entitas untuk mencapai status itu. Itu berarti model harus tahu cara memvalidasi sendiri.

Tetapi ada sedikit masalah: validasi model sering terjadi terlambat. Seringkali, kami ingin melakukan validasi lebih awal, sehingga pengguna tidak perlu menunggu terlalu lama. Itu sebabnya validasi sering dimasukkan ke dalam logika aplikasi.

Adapun konteks validasi: Tidak ada masalah entitas dapat meminta data tambahan. Tapi seharusnya tidak peduli dari mana data itu berasal. Tidak peduli apakah itu berasal dari SQL, File atau hanya kode keras. Itu sebabnya repositori ada. Domain menentukan jenis permintaan yang dibutuhkan dan memungkinkan orang lain untuk mengurus implementasinya.

Lapisan domain harus berisi semua logika validasi. Presentasi, lapisan anti korupsi atau lapisan ketergantungan lainnya harus mencerminkan hal itu.