Saya belajar di bersih dan sebagai hasilnya saya secara dramatis memikirkan kembali banyak cara saya merancang dan menulis perangkat lunak.
Namun saya masih bergumul dengan aturan bisnis seperti "simpan pembaruan untuk beberapa item, muat pertama Semua daftar item yang saya miliki izin untuk melihat / mengedit dll, mengkonfirmasi bahwa item ini ada dalam daftar, dan bahwa kategori item saat ini tidak dikunci dari penggunaan, (dan aturan lainnya, dll, dll) ".. karena itu adalah aturan bisnis (kompleks tetapi tidak atipikal), dan karenanya harus ditangani dalam domain aplikasi daripada mendorong logika bisnis ke dalam lapisan db / kegigihan.
Namun bagi saya tampaknya untuk secara efisien memeriksa kondisi ini sering kali akan lebih baik ditangani dengan permintaan db yang dibuat dengan baik, daripada memuat semua data ke dalam domain aplikasi ...
Tanpa optimasi prematur, apa pendekatan yang disarankan atau beberapa artikel paman Bob yang berurusan dengan pertanyaan ini? Atau akankah dia mengatakan "validasi dalam domain sampai menjadi masalah" ??
Saya benar-benar berjuang untuk menemukan contoh / sampel yang bagus untuk apa pun selain yang paling dasar dari kasus penggunaan.
Memperbarui:
Hai semua, terima kasih atas balasannya. Seharusnya saya lebih jelas, saya telah menulis perangkat lunak (kebanyakan aplikasi web) untuk waktu yang lama, dan sudah pasti sudah berpengalaman dan setuju dengan semua topik yang Anda uraikan secara kolektif (validasi dengan backend, jangan percaya data klien, secara umum kejar efisiensi mentah hanya jika diperlukan, namun akui kekuatan alat db saat tersedia, dll.) dan telah melalui siklus pembelajaran pengembang "membuang semuanya" untuk "membangun pengendali lemak raksasa dengan aplikasi N-tiers" tren kode , dan sekarang benar-benar menyukai dan menyelidiki gaya bersih / tanggung jawab tunggal dll, pada dasarnya sebagai hasil dari beberapa proyek baru-baru ini yang berkembang menjadi aturan bisnis yang cukup kikuk dan didistribusikan secara luas seiring proyek berkembang dan kebutuhan klien lebih lanjut terungkap.
Secara khusus, saya melihat arsitektur gaya bersih dalam konteks membangun REST apis untuk menghadapi klien serta fungsionalitas penggunaan internal, di mana banyak aturan bisnis mungkin jauh lebih kompleks daripada pada dasarnya setiap contoh yang Anda lihat di internet (Bahkan oleh arsitektur Clean / Hex guys sendiri).
Jadi saya kira saya benar-benar bertanya (dan gagal menyatakan dengan jelas) tentang bagaimana Bersih dan api REST akan duduk bersama, di mana sebagian besar barang MVC yang Anda lihat hari ini memiliki validator permintaan yang masuk (mis. Perpustakaan FluentValidation di .NET), tetapi di mana banyak aturan "validasi" saya tidak terlalu banyak "apakah ini string kurang dari 50 karakter" tetapi lebih "dapatkah pengguna ini memanggil usercase / interaksor ini melakukan operasi ini pada kumpulan data ini mengingat bahwa beberapa objek terkait saat ini dikunci oleh Tim X sampai akhir bulan dll dll "... validasi semacam itu sangat terlibat di mana BANYAK objek domain bisnis dan aturan domain berlaku.
Haruskah saya mengubah aturan-aturan itu menjadi jenis tertentu dari tipe objek Validator untuk menemani setiap pengguna-interaksi (terinspirasi oleh proyek FluentValidator tetapi dengan lebih banyak logika bisnis dan akses data yang terlibat), haruskah saya memperlakukan validasi seperti Gateway, haruskah saya letakkan validasi tersebut DI gateway (yang saya pikir salah), dll.
Sebagai referensi, saya pergi beberapa artikel seperti ini , tetapi Mattia tidak banyak membahas validasi.
Tapi saya kira jawaban singkat untuk pertanyaan saya mirip dengan jawaban yang saya terima: "Tidak pernah mudah, dan itu tergantung".