Comments 5
Понимаете, у вас проблема не с маппером а с тем что развели батальон различных слоев которые между собой нужно маппить. Вам зачем на мобильном приложении четыре слоя данных, вы от кого защищаетесь и абстрагируетесь? На backend нужны транспортные модели потому что могут быть разные клиенты и транспорты и самое главное - версии, бизнес модели для БД, и наконец backend ходит в интеграцию где используем не свои модели.
А вы в приложении что со всеми этими четырьмя слоями делаеме, от кого абстрагируетесь, от собственного экрана? Я понимаю ну допустим транспортные DTO как точка интеграции с backend потому что мб вы это не контролируете(и это плохо). Но остальные то к чему? Делать вид что мобильное приложение это backend сервис? К чему городить четыре слоя три из которых бесполезные создавая себе проблему чтобы потом героически превозмогать?
Блин, я думал, что здесь про Kerbal Space Program(
Мапперы - это “мёртвая зона”: они пишутся механически, но при этом легко ломаются и не приносят никакой ценности бизнесу.
Это прекрасно. Бизнес. Value... Раз мы такие бизнес-ориентированные - нафига писать маперы? Или может в ним есть некая ценность? Просто формулируемая не "здесь и сейчас" и как часть скажем некоего параметра maintenability?
По поводу общей сложности и синдрома второй системы мне добавить нечего.
Но про бизнес - это просто прекрасно.
Кстати - надо бы ещё и про "карбоновый след" не забыть добавить в следующей статье и словить бинго.
Все мапперы правятся нейронкой без проблем, тянуть какую то либо бе надобности. У нас на мобеилке отказались от домейн слоя - с даты на юуай , юзкнйсы с одним методом не нужны
Как мы перенесли ответственность за поддержку мапперов моделей на KSP