Czyli w tym DDD to rzeczywiście trzeba dużo pisać.
Nie powiedzialbym. Na początku może się to wydawać dużo, ale trzeba pamiętać, że wtedy zachowujemy SRP (jeden powód do zmian) i wszystko generalnie jest proste, a jak pakujesz to jednej klasy to ona rośnie, komplikuje się, czasami niektóre rzeczy są ze sobą w konflikcie.
Tylko w jakim folderze umieszczać te klasy do widoków? Związanym z widokami, czyli gdzieś na poziomie już templatów czy gdzieś w modelu? I pod jaką nazwą?
Jak chcesz, jak ci pasuje, nie ma konwencji. To generalnie bedą zwykłe DTOsy, możesz nazwac je też widokami, ostatnio ktoś na forum wrzucił to do pakietu api, bo faktycznie to jest kontrakt modułu. Pakiet dto/view też były OK, nie ma reguł.
A co powiesz o tym:
I czy jeśli w encji są funkcje biznesowe to czy to nie jest naruszenie SRP i właśnie nie powinno być w serwisach?
To jest naruszenie SRP, ale z innego powodu. Generalnie pomijając DDD obiekty mają zachowania (w tym funkcje biznesowe). Więc trzymanie całej logiki w serwisach jest złem, bo nie jest obiektowe i intuicyjne (tytuł tematu). Zatem wg purystów powinieneś mieć osobną klasę, która będzie reprezentować obiekt/model domenowy i osobną klasę encje (do mapowania na bazę danych czy co tam chcesz). Wtedy nie musisz mieć nic w serwisach. Oczywiście pisząc zwykłe aplikacje będą serwisy, bo nie można wszystkiego trzymać w modelu domenowym (zależności do innych serwisów, innych agregatów). IMHO proste rozróżnienie co w serwisie co w obiekcie domenowym: zapłać dla faktury - ustawienie pól, sprawdzenie warunków, przejście w inny stan - to się dzieje w obiekcie domenowym. Wysłanie maila do klienta z potwierdzeniem o płatności - to się dzieje w serwisie. Generalnie to faktura wie kiedy może być opłacona i w jaki sposób, żaden serwis nie musi zaglądać do jej środka i internali. Ale taka faktura to już nie ma zielonego pojęcia o zewnętrznym świecie i jakiś mailach, więc robi to serwis odpowiedzialny za to.