А решает он проблему печатанья тупого кода, но для меня печатать код никогда не было бутылочным горлышком разработки

Иногда DTO нужны, но не для всего же массово хуярить

Если у тебя в разных слоях модели с идентичной структурой — возможно, ты что-то делаешь не так. Но не факт.

как и DI фреймворки, в общем-то

Во флудильню идите

Надоели уже :)

да вроде по делу!!1

фшарп обсуждаем

Даладно

Да пока тут всё мелко, поэтому идентичность слоёв весьма ожидаема. Со временем она, вероятно, уменьшится

я бы не стал лепить одни и теже модели с ДТО пока они не нужны

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

у меня вот щас апишка есть на котлене с кучей моделек. Пока что дто пригодились только для юзер инпута где всё нуллабл строка без типов
потом валидация, валидация и внезапно из этой одной ДТО может выйти 5 других строго типизированных моделей. В кассандре они вообще по-другому хранятся, потому что кассандра - ебанутое хранилище для ебанутых (мне ок) и там на одну модель домена я например делаю 6 таблиц

где 3 таблицы это одни и те же данные с разным партишн ки для быстрого доступа (да, храню одно и то же в 3х экземплярах), а ещё 3 таблицы сугубо специализированные таблицы для поиска по временным интервалам

и это всё для одной модели!

У нас, например, есть в проде такой кейс:
Есть доменный слой моделей, и ДАЛ модели, которые мы в базу складываем. И, поскольку мы используем документное хранилище, эти модели почти идентичны (на старте были совсем идентичны)

Но мы специально сделали отдельный слой, чтобы при добавлении/изменении полей, в дата слое расставлять option, ибо у существующих данных этого поля в базе нет, а при маппинге в домен просто выставляем дефолтное значение. В итоге доменная модель остается чистой, и option там стоит только у тех полей, которые действительно опциональны по бизнес логике.

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

cc @Prunkles @omgszer

благодаря этому доменные модели у нас вообще как документация, кстати

Ну неплохо же

посмотрел — и сразу понятно, какие бизнес правила в этом куске

А почему нельзя иметь чистую модель на бизнесс логике и чистую модель в данных - условно говоря два набора record'ов.
Из бл набора в дл набор конвертировать явно и тут компилятор в помощь.
А в Json из дл моделей для хранилища и из бл моделей для апи гнать рефлексией без ручных маппингов?