Saya memiliki aplikasi ASP.NET MVC, yang menggunakan layanan kueri untuk mendapatkan data dan layanan perintah untuk mengirim perintah. Pertanyaan saya adalah tentang bagian perintah.
Jika permintaan masuk, layanan perintah menggunakan dispatcher perintah yang akan merutekan perintah ke penangan perintah yang ditunjuk. Penangan perintah ini memvalidasi perintah terlebih dahulu dan jika semuanya dapat diterima, itu menjalankan perintah.
Contoh nyata: AddCommentToArticleCommandHandler menerima AddCommentToArticleCommand, yang memiliki ArticleId, CommentText dan EmailAddress.
Pertama; validasi harus terjadi, seperti: - periksa apakah artikel ada - periksa apakah artikel tidak ditutup - periksa apakah teks komentar diisi dan antara 20 dan 500 karakter - periksa apakah alamat email diisi dan memiliki format yang valid.
Saya ingin tahu di mana harus meletakkan validasi ini?
1 / di command handler itu sendiri. Tapi kemudian, itu tidak dapat digunakan kembali di penangan perintah lainnya.
2 / dalam entitas domain. Tetapi karena entitas domain tidak tahu tentang repositori atau layanan, ia tidak dapat melakukan validasi yang diperlukan (tidak dapat memeriksa apakah ada artikel). Tetapi di sisi lain, jika entitas tidak mengandung logika, maka itu akan menjadi wadah data sederhana, yang tidak mengikuti prinsip-prinsip DDD.
3 / penangan perintah menggunakan validator, sehingga validasi dapat digunakan kembali di penangan perintah lainnya.
4 / Mekanisme lainnya?
Saya mencari rantai tanggung jawab untuk contoh khusus ini dan objek apa (entitas, repositori, ...) yang berperan di dalamnya.
Apakah Anda memiliki ide tentang bagaimana Anda akan mengimplementasikan ini, mulai dari penangan perintah hingga repositori?
Jawaban:
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:
Validasi aplikasi
Antrean agregat root + racun tidak ada
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
sumber
EDIT: WaybackMachine tautan: http://devlicio.us/blogs/billy_mccafferty/archive/2009/02/17/a-response-to-validation-in-a-ddd-world.aspx
Tidak ada jawaban tepuk.
sumber