Saya pikir Anda perlu memisahkan dua jenis validasi dalam kasus ini; validasi domain dan validasi aplikasi .
Validasi aplikasi adalah apa yang Anda miliki ketika Anda memverifikasi bahwa properti teks perintah 'adalah antara 20 dan 200 karakter; jadi Anda memvalidasi ini dengan GUI dan dengan view-model-validator yang juga dijalankan di server setelah POST. Hal yang sama berlaku untuk e-mail (btw, saya harap Anda menyadari bahwa e-mail seperti `32.d +" Hello World .42 "@ mindomän.local" adalah valid menurut RFC).
Kemudian Anda memiliki validasi lain; periksa artikel itu ada - Anda harus bertanya pada diri sendiri pertanyaan mengapa artikel itu seharusnya tidak ada jika memang ada perintah yang dikirim dari GUI yaitu tentang melampirkan komentar padanya. Apakah GUI Anda akhirnya konsisten dan Anda memiliki root agregat, artikel, yang dapat dihapus secara fisik dari penyimpanan data? Dalam hal ini Anda hanya memindahkan perintah ke antrian kesalahan karena penangan perintah gagal memuat akar agregat.
Dalam kasus di atas, Anda akan memiliki infrastruktur yang menangani pesan racun - mereka misalnya akan mencoba lagi pesan 1-5 kali dan kemudian memindahkannya ke antrian poision di mana Anda bisa secara manual memeriksa koleksi pesan dan mengirim kembali yang relevan. Ini hal yang baik untuk dipantau.
Jadi sekarang kita sudah membahas:
Bagaimana dengan perintah yang tidak sinkron dengan domain? Mungkin Anda memiliki aturan dalam logika domain Anda yang mengatakan bahwa setelah 5 komentar ke sebuah artikel, hanya komentar di bawah 400 karakter yang diperbolehkan, tetapi satu orang sudah terlambat dengan komentar ke-5 dan menjadi yang ke-6 - GUI tidak menangkapnya karena itu tidak konsisten dengan domain pada saat dia mengirimkan perintahnya - dalam hal ini Anda memiliki 'kegagalan validasi' sebagai bagian dari logika domain Anda dan Anda akan mengembalikan peristiwa kegagalan yang sesuai.
Acara tersebut bisa dalam bentuk pesan ke pialang pesan atau pengirim kustom Anda. Server web, jika aplikasinya monolitik, dapat secara sinkron mendengarkan acara sukses dan kegagalan yang disebutkan dan menampilkan tampilan yang sesuai / sebagian.
Seringkali Anda memiliki acara khusus yang berarti kegagalan untuk banyak jenis perintah, dan ini adalah acara yang Anda ikuti dari perspektif server web.
Dalam sistem yang sedang kami kerjakan, kami melakukan permintaan-respons dengan perintah / acara melalui broker pesan + broker MassTransit + RabbitMQ dan kami memiliki acara di domain khusus ini (memodelkan alur kerja sebagian) yang dinamai InvalidStateTransitionError. Sebagian besar perintah yang mencoba bergerak di sepanjang sisi dalam grafik keadaan dapat menyebabkan peristiwa ini terjadi. Dalam kasus kami, kami memodelkan GUI setelah paradigma yang akhirnya konsisten, dan karenanya kami mengirim pengguna ke halaman 'perintah diterima' dan kemudian membiarkan tampilan server web diperbarui secara pasif melalui langganan acara. Harus disebutkan bahwa kita juga melakukan event-sourcing di akar agregat (dan akan melakukan juga untuk kisah-kisah).
Jadi Anda lihat, banyak validasi yang Anda bicarakan sebenarnya adalah validasi tipe aplikasi, bukan logika domain aktual. Tidak ada masalah dalam memiliki model domain sederhana jika domain Anda sederhana tetapi Anda sedang melakukan DDD. Namun, saat Anda terus memodelkan domain Anda, Anda akan menemukan bahwa domain tersebut mungkin tidak sesederhana yang pertama kali terjadi. Dalam banyak kasus, agregat root / entitas mungkin hanya menerima pemanggilan metode yang disebabkan oleh perintah dan mengubah beberapa statusnya tanpa melakukan validasi apa pun - terutama jika Anda memercayai perintah Anda seperti yang akan Anda lakukan jika Anda memvalidasinya di server web yang kamu mengendalikan.
Saya dapat merekomendasikan menonton dua presentasi tentang DDD dari Norwegian Developer Conference 2011 dan juga presentasi Greg di Öredev 2010 .
Cheers, Henke