Не понял проблему. Тип а когда у тебя сущности у тебя проблемы такой нет? Или по какой-то причине количество dto будет сильно больше (на порядки?)? В чем проблема?

Ты про джойны и нормализацию?

> Тип а когда у тебя сущности у тебя проблемы такой нет?

В каком-то смысле да, т.к. подгружаются все связи.

> Или по какой-то причине количество dto будет сильно больше (на порядки?)?

10 считается? В каких-то местах нужна дтошка с одними связями, в какой-то — с другими. В третьей — с другими двумя и так далее. В результате хер пойми как это назвать. Тем более, если не указывать в названии что именно в дтошку добавлено (херня получается).

В том числе

Кроме это ещё время от времени всплывают мысли о том, что в идеале из базы нужно доставать только те поля, которые нужны (с целью минимизации потребляемой памяти, к примеру), а значит или нули в дтошке или отдельная дтошка...

Ну там всякие UserIdName ещё можно называть, а если там половина всех полей или все поля кроме трёх...

Не знаю.. Идеал найти не могу

Application side join

+ в целом просто именуешь dto под операцию чтения

Но дто то всё равно будет и назвать как-то её нужно...

Т.е. "что получим" или "для чего нужно"?

"Для чего нужно"

Когда как на самом деле

Тогда должно помочь, хм, да. Только, возможно, не будет сразу понятно что внутри, но это может быть второстепенным

Хотя какой Brief User profile это и "что" и " для чего"

Можешь у фронтов спросить как они называют компоненты хз

Это как с сущностями - всегда есть уточнения, люди просто не любят дальше юзера копать

Типа того и называл, но потом случались моменты, когда появляются ещё один чуть отличающийся. "MoreBriefUserProfile" :D

О, надо глянуть

Это обычно признак что нет системы/унификации.