Ну тогда если тебе нужны все ее поля, у тебя

какой вариант? Создать вью модель да заммапить, но как ты сам сказал (в другом примере) при необходимости это можно довольно просто сделать

Хотя офк может у фронтов появиться зависимость от данных, что ты вернул и как минимум убрать из такой вьюхи поля уже нельзя

Совпадения вью и доменки по полям практически не бывает, я такие кейсы даже придумать не в состоянии, если это конечно нормальная толстая модель по первоисточнику, а не анимичные подделки под ддд

Я хз, у меня моделей с большим количеством полей мало, можно их и один к одному соединять База то нормализована в большей степени

Ну не будете же вы доменку на круд формы писать? Нахера там логики то нет. Ну я надеюсь ))

Логики в круде? Или в доменке? Для меня доменки это entities для дбсета, а то может я не понимаю тебя 😀

В круде, логики нету обычно, валидаторы я бизнес логикой не считаю. И по сути там прямо в контроллере поднял/создал/удалил/изменил )) Какие там доменки к херам собачьим? )

Доменка в моем понимании сложный бизнес объект, агрегирующий множество сучностей БД, с логикой внутри самого объекта.

Ок, я попытаюсь представить Делаешь микросервис для круда одной таблицы Там вообще можно от всех слоев избавиться и юзать минимал апи, тогда и маппинг не понадобится

А микросервис то зачем? ))

Для меня доменка это поля с описанием ограничений и типов для таблицы в code first, поверх которой потом будет создана миграция, без какой либо логики в своем типе

Модно

А почему это доменка то? Это модель БД. Или сучность. Домен то тут причем?

Не важно, в микросервисе или в монолите суть не меняется

Ну да, именно это Ты уверен что это просто не синонимы?

Ну смотря по какой школе смотреть, щас все поизвращали напрочь, изначально архитектуру ддд предложил эванс, где и описывал домен как средство закрепления общего(ubiquitous) языка, непосредственно в проекте. Что щас пишут везде подряд всякие инициативные товарисчи это просто жесть... все термины нахрен поломали.

Мне просто слово entities в тыщу раз сложнее написать и произнести, хуже только queue

А чем русский вариант сучность не устраивает? )

В немйсмейсе и папку в проекте 😀 Project.Suchnosties

Гм, ну в проекте же это не одна папка, наверное, ну как бы делать одну папку на несколько тысяч классов такое себе...

Я это взял из простой трёхслойной архитектуры Где есть DAL слой, в котором и лежат модели бд

Я набаловался, этой хренью, с 18 года слоенка для меня ругательство. )

У меня нет проектов где тыща моделей бд в одном слое DAL 😀 Если это монолит то он все равно как то разбит на проекты где один слой веба просто ссылается на кучу BLL, которые в свою очередь ссылаются на DAL'ы Не ddd ли это? Вряд-ли

К чему в итоге пришел?

Никакой разбивки по проектам, достаточно разбивки по папкам, отдельно выделена папка Data, в которой по папкам разложены сучности, а остальное в паке futures, где по папкам вертикально порезан основной функционал, там рядышком лежат сервисы, контроллеры и модели. Отдельно еще есть папка сервицес, где лежат общие инфраструктурные сервисы, всякие парсеры, протоколы и прочая техническая муть. Ну и утилс конечно, как без них.

Понятно, ну это действительно проще в поддержке, но допустим читал кейсы Тинькова, где если бы так они все делали то не смогли бы разбить функционал так просто на две версии api, у них вариант с детским апи и взрослым апи, тоже самое с приложухами под ios Android А так все разбито по проектам и подключается только туда куда надо Приходит Джун на проект и юзает твой дбконтекст в контроллере, ибо все лежит в одном проекте А лежало бы в разных и именовалось по слоям, может он хоть задумался бы? 😀 Типы что помечены интернал могут быть использованы везде, ну крч инкапсуляция сильно ограничевается как по мне

Прекрасно разбиваем, у нас например несколько апи, для spa одно, для мобилок другое, для внешки третье.

В итоге в развернутом варианте на серваке будут dll ки содержащие типы, которые в этой версии api не юзаются?

Приходит Джун на проект и юзает твой дбконтекст в контроллере, ибо все лежит в одном проекте А лежало бы в разных и именовалось по слоям, может он хоть задумался бы? 😀> Наоборот стало проще с джунами, они лучше понимают что куда, а зависимостях слоев вечно путались что куда пихать, проходили жесть была )

Но это все равно слои только по папкам, ты далеко же не ушел, хех)

Серер то один что значит не юзаются?

Аа, тогда вопросов нет

нет слоев, вертикальная нарезка

Приходит Джун на проект и юзает твой дбконтекст в контроллере, ибо все лежит в одном проекте => Так мы юзаем дб контекст в контроллерах, мне вообще не понятна истерия по поводу того что ай ай ай, в контроллере дб контекст обнаружен, все кабздец. Ничего страшного в этом как бы нет, выделять тот же сервис для тех же крудов и начинать автомапить все подряд, это гораздо хуже на мой взгляд, от того что этот код из контроллера вынесли мало что поменялось, а как я и писал выше если почесалось переиспользовать то вынести в отдельный класс дело 5 минут, а до того пусть там и лежит.

Ну в общем kiss и yagni

Ога они родимые ))

Все эти принципы сами себе противоречат, я понял что осознать их и главное применять можно только исходя из нехилого опыта, когда жопой уже чуешь что тут не изменится и можно сделать проще и т д

Можно просто не боятся изменений ) А когда лишнего не наворачиваешь изменять сильно проще, мы например при существенном изменении требований бывает что всю папку с функцинальностью нафиг сносим и просто заново пишем )

У меня галера где проекты делятся на маленькие команды, я например на своих тупо один, причем ещё и фуллстачу Поэтому не могу просто снести и заново написать 😀, мне скажут что я охренел столько времени тратить)

Ну это же не архитектурный вопрос, а вопрос организации труда на конкретном рабочем месте. Да и опять же насчет времени, если вы не будете херней маятся со слоями и прочей ерундой то и времени на переписывание потребуется сильно меньше )

База

Что база?

субд

Что субд?

База

Та-та-да-та-там )