To ja mam również pytanie, bo akurat sam się uczę takich rzeczy: czy w przypadku kolegi wystarczy zrobić odpowiednie klasy Entity reprezentujące bazy danych, a następnie stworzyć obiekt DTO by pobierać z niego numery telefonów? Czy to bez sensu i nie do tego służy DTO?
Ogólnie powinieneś budować aplikacje wokół czegoś co się nazywa obiekty biznesowe (encje biznesowe). Te obiekty/encje biznesowe mają odwzorowywać domenę czyli twój problem najlepiej jak się da (są modelem domeny). W idealnym świece powinny być to jedyne obiekty danych (encje) jakie potrzebujesz.
Ponieważ nie żyjemy w idealnym świece jest prawdopodobne że będziesz potrzebować encji (obiektów danych) bazodanowych do komunikacji z bazą danych. To prawdopodobieństwo rośnie proporcjonalnie do czasu życia aplikacji. Czyli im dłużej żyje aplikacja tym bardziej prawdopodobne że model domeny będzie się nie zgadzać z modelem w bazie danych i będzie potrzebne mapowanie w kodzie między modelami.
Jeszcze częstszym przypadkiem jest mapowanie modelu domeny na DTO (Data Transfer Object) czyli obiekty dedykowane do przesyłania przez sieć. W DTO często są spłaszczone (dane w nich mają mało poziomów zagłębień) w przeciwieństwie do encji z modelu domenowego gdzie stara się agregować podobne pola razem w obiekty i walczy się o to żeby żadna klasa nie miała 10 czy 20 pól (co w DTO się zdarza)
Ogólnie jak będziesz pisać prostego CRUDa na inżyniera/magisterkę czy żeby nauczyć się nowego wspaniałego frameworka to na 90% model domeny będzie identyczny z modelem bazy danych i z modelem DTO i żadne mapowania nie będą potrzebne