Saya sedang mendesain ulang aplikasi berskala besar, kami menggunakan arsitektur multi-layer berdasarkan DDD.
Kami memiliki MVC dengan lapisan data (implementasi repositori), lapisan domain (definisi model domain dan antarmuka - repositori, layanan, unit kerja), lapisan layanan (implementasi layanan). Sejauh ini, kami menggunakan model domain (sebagian besar entitas) di semua lapisan, dan kami menggunakan DTO hanya sebagai model tampilan (di controller, layanan mengembalikan model domain (s) dan controller membuat model tampilan, yang diteruskan ke tampilan).
Saya sudah membaca banyak artikel tentang menggunakan, tidak menggunakan, memetakan dan melewati DTO. Saya mengerti bahwa tidak ada jawaban pasti, tetapi saya tidak yakin apakah itu ok atau tidak mengembalikan model domain dari layanan ke pengontrol. Jika saya mengembalikan model domain, itu masih tidak pernah diteruskan ke tampilan, karena pengontrol selalu membuat model tampilan khusus tampilan - dalam hal ini, tampaknya sah. Di sisi lain, rasanya tidak benar ketika model domain meninggalkan lapisan bisnis (lapisan layanan). Terkadang layanan perlu mengembalikan objek data yang tidak didefinisikan dalam domain dan kemudian kami harus menambahkan objek baru ke domain yang tidak dipetakan, atau membuat objek POCO (ini jelek, karena beberapa layanan mengembalikan model domain, beberapa mengembalikan DTO secara efektif).
Pertanyaannya adalah - jika kita benar-benar menggunakan model tampilan, apakah boleh mengembalikan model domain sepenuhnya ke pengontrol, atau haruskah kita selalu menggunakan DTO untuk komunikasi dengan lapisan layanan? Jika demikian, apakah boleh menyesuaikan model domain berdasarkan kebutuhan layanan apa? (Sejujurnya saya tidak berpikir begitu, karena layanan harus menggunakan domain apa yang dimiliki.) Jika kita harus tetap berpegang teguh pada DTO, haruskah mereka didefinisikan di lapisan layanan? (Saya pikir begitu.) Kadang-kadang jelas bahwa kita harus menggunakan DTO (misalnya, ketika layanan melakukan banyak logika bisnis dan membuat objek baru), kadang-kadang jelas bahwa kita harus menggunakan model domain yang adil (misalnya, ketika layanan Keanggotaan mengembalikan Pengguna yang anemia ( s) - sepertinya tidak masuk akal untuk membuat DTO yang sama dengan model domain) - tapi saya lebih suka konsistensi dan praktik yang baik.
Domain Artikel vs DTO vs ViewModel - Bagaimana dan Kapan menggunakannya? (dan juga beberapa artikel lainnya) sangat mirip dengan masalah saya, tetapi tidak menjawab pertanyaan ini. Artikel Haruskah saya menerapkan DTO dalam pola repositori dengan EF? juga mirip, tetapi tidak berurusan dengan DDD.
Penafian: Saya tidak bermaksud menggunakan pola desain apa pun hanya karena ada dan mewah, di sisi lain, saya ingin menggunakan pola dan praktik desain yang baik juga karena membantu merancang aplikasi secara keseluruhan, membantu pemisahan masalah, bahkan untuk menggunakan pola tertentu tidak "diperlukan", setidaknya saat ini.
Seperti biasa, terima kasih.