Logika penyaringan harus dalam repositori atau dalam layanan?

Saya ingin tahu yang berikut: misalkan kita sedang membangun sistem di mana perlu ada beberapa fungsi penyaringan untuk mencari beberapa entitas. Misalnya, orang mungkin ingin menerapkan pemfilteran ke tabel yang mencantumkan entitas untuk menemukan sesuatu, atau menggunakannya untuk menghasilkan laporan pada perangkat yang difilter, apa pun.

Intinya adalah: kita perlu memiliki logika penyaringan di suatu tempat. Salah satu cara buruk untuk melakukan ini adalah dengan mereplikasi logika penyaringan di mana diperlukan. Saya pernah melakukannya sekali dan itu adalah satu ide yang mengerikan.

Di sisi lain, saya percaya harus ada metode seperti yang Filter(FilteringOptions filteringOptions)dirancang untuk melakukan operasi penyaringan dan mengembalikan daftar entitas yang difilter.

Sekarang, IMHO, logika penyaringan adalah jenis logika bisnis. Para pakar bisnis adalah orang-orang yang tahu bagaimana penyaringan terjadi, hal-hal apa saja yang disaring dan bagaimana caranya. Karena itu, saya percaya logika penyaringan harus terletak di lapisan domain.

Saya telah menemukan dua opsi untuk melakukan ini: menanamkan metode pemfilteran dalam repositori yang sesuai untuk entitas tertentu, atau yang lain, membuat layanan domain seperti EntityNameSearchServiceyang akan mengkonsumsi repositori untuk melakukan penyaringan.

Saya masih bingung mana yang akan menjadi cara yang lebih baik. Jadi, jika saya mencoba menggunakan DDD dengan benar, di mana logika penyaringan ini seharusnya? Di repositori atau di layanan terpisah?

domain-driven-design search filtering

— pengguna1620696
sumber

Di mana logika penyaringan paling masuk akal bagi Anda, dari perspektif rawatan dan kegunaan?

— Robert Harvey

Sepintas tampaknya dalam repositori, karena itu adalah objek yang bertanggung jawab untuk, antara lain, mengambil entitas. Di sisi lain, logika penyaringan tidak perlu diterapkan hanya pada pengambilan, itu dapat diterapkan ke daftar entitas apa pun. Memang, memikirkan sedikit lebih banyak tentang hal itu, lapisan domain hanya berisi antarmuka repositori. Implementasi aktual terletak pada proyek Data dan harus digabungkan dengan mekanisme ketekunan yang sebenarnya, sementara layanan diimplementasikan pada domain. Dari sudut pandang ini menciptakan layanan penyaringan tampaknya lebih masuk akal.

— user1620696

Pemfilteran dalam lapisan layanan akan memakan waktu lebih lama daripada mendapatkan data yang sudah difilter dari repositori melalui metode yang ditargetkan, tetapi Anda dapat menggunakan kembali Get*metode generik dan memperkenalkan filter yang berbeda atau yang ditentukan pengguna di lapisan layanan. Keputusan sebagian besar terserah Anda.

— Andy

Saya ingin tahu yang berikut: misalkan kita sedang membangun sistem di mana perlu ada beberapa fungsi penyaringan untuk mencari beberapa entitas. Misalnya, orang mungkin ingin menerapkan pemfilteran ke tabel yang mencantumkan entitas untuk menemukan sesuatu, atau menggunakannya untuk menghasilkan laporan pada perangkat yang difilter, apa pun.

Anda harus mengamati bahwa titik ini bahwa kasus penggunaan Anda untuk memfilter pusat membaca , daripada menulis. Ini adalah pola normal - penulisan biasanya ditujukan ke akar agregat tertentu di domain Anda.

Jika Anda melakukan membaca, maka Anda sebenarnya tidak peduli dengan agregat - Anda tidak peduli tentang penegakan invarian bisnis karena Anda tidak benar-benar mencoba mengubah apa pun. Anda hanya peduli tentang keadaan.

Yang mungkin berarti masuk akal untuk mem-bypass model domain sepenuhnya.

Hanya sesuatu untuk dipikirkan.

Sekarang, IMHO, logika penyaringan adalah jenis logika bisnis. Para pakar bisnis adalah orang-orang yang tahu bagaimana penyaringan terjadi, hal-hal apa saja yang disaring dan bagaimana caranya. Karena itu, saya percaya logika penyaringan harus terletak di lapisan domain.

Iya dan tidak. Anda menggunakan bahasa di mana-mana untuk menggambarkan filter. Jadi Anda pasti menggunakan kosa kata domain.

Tetapi Anda tidak memiliki "perilaku" apa pun, sejauh Anda tidak benar-benar memodifikasi buku catatan, sehingga Anda tidak perlu khawatir.

Di sisi lain, saya percaya harus ada metode seperti Filter (FilteringOptions filteringOptions) yang dirancang untuk melakukan operasi penyaringan dan mengembalikan daftar entitas yang disaring.

Anda sangat dekat dengan gagasan "Spesifikasi" . Ini pada dasarnya merupakan predikat daripada repositori yang dapat digunakan untuk mengidentifikasi artefak mana yang cocok dengan beberapa kriteria arbitrer.

Ada beberapa perangkap yang harus diperhatikan. Greg Young menyentuh mereka beberapa waktu lalu, tetapi saya akan meringkas di sini.

Pertama, abstraksi menjalankan predikat terhadap koleksi adalah O (N). Anda mungkin menginginkan sesuatu yang lebih baik, terutama jika toko kegigihan Anda cerdas dalam mengindeks. Komponen ketekunan Anda mungkin ingin dapat mengubahnya menjadi kendala spesifik implementasi (contoh: mengambil spesifikasi dan mengubahnya menjadi klausa di mana pada pernyataan yang disiapkan).

Kedua, antarmuka adalah sarana untuk mendokumentasikan kontrak yang dilayani oleh komponen ketekunan. "Jadikan implisit eksplisit" - jika Anda mendeskripsikan apa yang benar-benar Anda butuhkan, maka antarmuka memberi tahu Anda sesuatu tentang karakteristik apa yang penting bagi penyimpanan data Anda, yang memberi Anda satu tempat untuk dilihat ketika mencoba mengevaluasi apakah suatu alternatif toko cocok.

(Tentu saja, implementasi antarmuka itu mungkin hanya adaptor yang menciptakan spesifikasi dari argumen metode, dan meneruskannya. Tidak apa-apa, Anda sudah menangkap persyaratan yang sebenarnya).

— VoiceOfUnreason
sumber