Projektuję (re) dużą aplikację, używamy architektury wielowarstwowej opartej na DDD.
Mamy MVC z warstwą danych (implementacja repozytoriów), warstwą domenową (definicja modelu domeny i interfejsów - repozytoria, usługi, jednostka pracy), warstwą usługową (implementacja usług). Do tej pory używamy modeli domenowych (głównie encji) na wszystkich warstwach, a DTO używamy tylko jako modeli widoku (w kontrolerze usługa zwraca model (y) domeny, a kontroler tworzy model widoku, który jest przekazywany do widoku).
Czytałem niezliczone artykuły o używaniu, nieużywaniu, mapowaniu i przekazywaniu DTO. Rozumiem, że nie ma żadnej ostatecznej odpowiedzi, ale nie jestem pewien, czy jest to w porządku, czy nie zwracam modeli domeny z usług do kontrolerów. Jeśli zwracam model domeny, nadal nie jest on przekazywany do widoku, ponieważ kontroler zawsze tworzy model widoku specyficzny dla widoku - w tym przypadku wydaje się to uzasadnione. Z drugiej strony nie wydaje się dobrze, gdy model domeny opuszcza warstwę biznesową (warstwę usług). Czasami usługa musi zwrócić obiekt danych, który nie został zdefiniowany w domenie, a następnie albo musimy dodać nowy obiekt do domeny, która nie jest mapowana, albo utworzyć obiekt POCO (jest to brzydkie, ponieważ niektóre usługi zwracają modele domeny, niektóre skutecznie zwrócić DTO).
Pytanie brzmi - jeśli ściśle używamy modeli widoku, czy można zwracać modele domeny aż do kontrolerów, czy też powinniśmy zawsze używać DTO do komunikacji z warstwą usług? Jeśli tak, czy można dostosować modele domen w oparciu o potrzebne usługi? (Szczerze mówiąc, nie sądzę, ponieważ usługi powinny zużywać to, co ma domena.) Jeśli powinniśmy ściśle trzymać się DTO, czy powinny być zdefiniowane w warstwie usług? (Myślę, że tak.) Czasami jest jasne, że powinniśmy używać DTO (np. Gdy usługa wykonuje dużo logiki biznesowej i tworzy nowe obiekty), czasami jest jasne, że powinniśmy używać tylko modeli domeny (np. Gdy usługa członkostwa zwraca anemiczny użytkownik ( s) - wydaje się, że nie miałoby sensu tworzenie DTO, które jest takie samo jak model domeny) - ale wolę spójność i dobre praktyki.
Artykuł Domena vs DTO vs ViewModel - jak i kiedy ich używać? (a także kilka innych artykułów) jest bardzo podobny do mojego problemu, ale nie zawiera odpowiedzi na to pytanie (a). Artykuł Czy za pomocą EF należy implementować DTO we wzorcu repozytorium? jest również podobny, ale nie dotyczy DDD.
Zastrzeżenie: nie zamierzam używać żadnego wzorca projektowego tylko dlatego, że istnieje i jest fantazyjny, z drugiej strony chciałbym używać dobrych wzorców i praktyk projektowych również dlatego, że pomaga projektować aplikację jako całość, pomaga w oddzieleniu obaw, nawet jeśli używanie określonego wzorca nie jest „konieczne”, przynajmniej w tej chwili.
Jak zawsze dziękuję.