Парамонdto, который один сервис отправил, а другой принял - один и тот же dto, и если он изменился, то это дожно произоити у всех.
или отправленный dto просто похож и киент должен его продублировать?

про Swagger уже было сказано, так же что у SOAP, что у той же OData есть контракты, позволяющие тебе сгенерировать классы у клиентов для любых языков.

где ты видел, чтобы поставляли DLL-ки с DTO-шками?

Парамоннекий cms получает список товаров из сервиса.
в товар добавили новое поле.
cms автоматом его получит обновив сборку.
нет дублирования, профит.

т.е. ты не видишь тут очевидной проблемы, в этом "решении"?

Парамонмы не говорим про открытые апи, а в рамках своих проектов.

ты проблемы не видишь да?

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

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

ПарамонhVosttты проблемы не видишь да?

проблем тут полно, в чем фатальная? )

в том, что путаешь контракт сервиса и контракт передачи данных, DTO является контрактом сервиса, а не передачи данных.

Парамонпочему dto не может использоватся в качестве контракта передачи данных?

Потому что у тебя создана прямая зависимость двух отдельных друг от друга сервисов. Добавление поля съест любой сервис, но это не означает, что будет поддерживаться логика, и узнать об этом невозможно до возникновения реальных проблем. Использование в микросервисах выглядит ещё более странно, контракты должны быть простыми.

ПарамонОбычно добавление поля делают для клиента, и зачастую по его запросу.

Ты говорил речь не идёт о публичном АПИ. Темнишь..


ПарамонА как еще изменить поле не нарушив логику клиента?
Дальше версионность api, но это не по теме dto.

Всё же я говорил про DTO, а не про АПИ.

Парамон,

Доходит до того, что в сервисные DTO пихают поля, нужные клиенту в его АПИ. А потом выпячивая грудь говорят: зато код не дублируется... вы чего, с дуба рухнули? )))))

ПарамонhVosttДоходит до того, что в сервисные DTO пихают поля, нужные клиенту в его АПИ. А потом выпячивая грудь говорят: зато код не дублируется... вы чего, с дуба рухнули? )))))
в dto пихают то, что нужно передать кому либо.
проблема где?

ещё раз, в dto добавляется поле, которое напрямую влияет или связана с логикой, по сути все поля в dto имеют смысл для клиентов классов сервисов. то, что сериализуется куда-то там JSON, это не DTO, это модели для сериализации. то, что DTO совпадает с этими моделями, это всего лишь удачный частный случай, но строить вокруг этого архитектуру -- ошибка.

вот пример, в dto добавляется поле с ндс, так как теперь он вытаскивается из цены и теперь цена кардинально меняет смысл и меняется расчёты, меняются отчёты, меняется то вид данных. но сервисы с обновлёнными dto прекрасно компилируются и даже работают.

также апи может мультиплексировать данные в целях для оптимизации канала, передавать тех. поля, данные для контроля целостности, актуальности и т.п. когда архитектура построена на DTO=API, это всё впихивают в классы, которые болтаются мёртвым грузом на слое работы с данными и не дают обеспечить нормальное тестирование.

Парамон,

проблема наверное таки в терминологии. потому что ты называешь DTO классы моделей для АПИ, ничего дурного нет, если ты выделишь такие модели в отдельную сборку. но это не те классы, которые должны использоваться для работы сервисов бизнес-логики, они возвращают свои DTO, ты из конвертишь в модели. если что-то меняется в моделях, не важно, просто добавляешь поле, меняешь их, или объединяешь данные разных DTO для результата АПИ, это не оказывает влияния на сервисы, просто меняется контракт. вот это дело.