symfony/serializer-ом. весьма удобно

даже если у тебя вдруг не 1:1 мэппинг DTO - всегда можно нормалайзер свой зарегать

Типа мапишь json или че там прямо на DTO?

да

Ясн

если надо не прямо - регаешь свой нормалайзер или даже свой ресолвер

А логика прям в доктрин энтитях?

ну вот в примере выше это prooph а не доктрина)

но в целом да

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

там где сложно дергаю сервис

но то что я пока для себя понял - мне не нужна доктрина

Prooph это какой-то упрощенный маппер или что?

это такой недо nservicebus

типа хлипенький фреймворк для event sourcing

Ясн

И как, все нравится? Какие проблемы наблюдаешь?

с пруфом? но он примитивненький.

много чего приходится доделывать

Ну и вообще с твим подходом

но в целом приятнее чем с доктриной. правда юзать пруф для всего тоже не оч выгодно... ну это больше камень в огород стоимости event sourcing-а

у нас только часть сущностей (самое важное) через ES менеджатся. И часть через доктрину.

Ну и вообще с твим подходом

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

Модули это ивент листенеры?

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

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

короч... загоны по "респонс как композиция данных"

А, я понял

наверное

ну вот у меня те же чувства.... я вроде понимаю чего хочу но как-то не очень)

А как тесты на бизнес логику?

@fes0r Насколько я понял про типы наследования - это мюсли самого автора? https://www.sicpers.info/2018/03/why-inheritance-never-made-any-sense/ Или есть какой-то источник, который стоит почитать на эту тему?

А кто автор?

А кто автор?

я этого товарища не знаю

А кто автор?

https://www.sicpers.info/about/ как-то так

как звучит фраза roadroute? Норм для домена?

как звучит фраза roadroute? Норм для домена?

Какая же это фраза, это целый абзац.

как звучит фраза roadroute? Норм для домена?

Очень плохо

Очень плохо

чего так?)

чего так?)

Ну может не плохо-плохо, но как-то непонятно. Что обозначает ваше roadroute. Вот со стороны пытаюсь понять и получается "маршрут дороги" (в общем масло масленое)

дорожний маршрут, если есть маршруты не только по дорогам то норм

Хотел вот обсудить такой момент. Если допустим у нас апи и мы берем результат какого-то запроса, может это энтити или дто, сериализуем, отправляем в json. В клиенте десериализуем в какой-то тоже там энтити или дто. И на мой вкус, получается, мы этим самым жестко связали эту энтити в сервере с энтити в клиенте. Кто-то изменит поле в сервере и клиент отвалится, а способа это проверить в большом проекте может и не быть надежного

json schema

Даже если есть, ты изменишь энтити и где-то апи уже не будет соответствовать схеме

И если ты не знаешь что оно там где-то сериализуется, то и не посмотришь

тесты для слабаков

Да

Ну тесты немного помогают конечно тут

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

не немного, а полностью

Очень просто у тебя все :)

у меня 4 сотни "дтошек", которыми взаимодействют 3 разных языка. не говори мне про простоту в сраной апишечке

любой дымовой тест полностью решает твою проблему

Конечно же на любую проблему в программировании есть один однозначный и правильный ответ и нечего тут обсуждать

обсуждать что?) что ты не в курсе как построить 2 одинаковых контракта? @thatside выше накинул. Никаких проблем

обсуждать что?) что ты не в курсе как построить 2 одинаковых контракта? @thatside выше накинул. Никаких проблем

проблема в том что это контракт и менять его сложно)

Я пока что остался непонят в этом чате

Я пока что остался непонят в этом чате

попробуй еще раз)

проблема в том что это контракт и менять его сложно)

да в целом, не сложно)

да в целом, не сложно)

дай ему мысль раскрыть)

Я веду к тому, что сериализация делает неявную связь между структурой DTO (или энтити, у кого там как) и API, а соответственно и клиентом

ммм.... я бы не сказал что она такая уж неявная

дай ему мысль раскрыть)

там дтошки и сущности - в общем-то одно и то же. да ещё и связь неявная (хоть и ногами забита, но типа неявная)

ну то есть, ты эскпоузишь какую-то модель данных, и клиентский код на эту модель данных завязан. Сериализация это лишь промежуточный этап для того что бы данные доставить. Ты можешь использовать что-то с жесткой схемой (grpc, thrift и прочие messagepack)

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

ERROR: S client not available

По хорошему нужно делать отдельные DTO для каждой апи и мапить твои модели на них

так?

и да и нет

так

ну то есть ДА в том плане что структура данных для UI должна быть жестко определена, что бы иметь возможность далее использовать ее для контрактов и проще проверять обратную совместимость (и ее поддерживать) и НЕТ в том плане что это может быть не просто класс

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

То же самое, если не API а сервер сайд рендеринг, объекты которые передаются на вью не очень хорошо если это прямо твои бизнес энтити, а надо отдельные делать и на них мапить

То же самое, если не API а сервер сайд рендеринг, объекты которые передаются на вью не очень хорошо если это прямо твои бизнес энтити, а надо отдельные делать и на них мапить

да

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

но опять-таки, это не решает проблему того, что в 1 месте dto ошку исправили, а в другой части системы нет - всё летит фпесту. И, да, тут тебе поможет либо одинаковая схема для обоих частей (чёт типо xsd, например), либо тесты.

дальше идет сравнение стоимости этого дела (а это делать всегда и везде дорого) и профита который ты получаешь. Риски (как часто меняется, насколько легко определить нарушение обратной совместимости)...

А как вы мапите свои бизнес энтити на эти вью dto объекты?

А как вы мапите свои бизнес энтити на эти вью dto объекты?

sql -> dto

не вижу смысла в read-only операциях вообще сущности юзать

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

но опять-таки, это не решает проблему того, что в 1 месте dto ошку исправили, а в другой части системы нет - всё летит фпесту. И, да, тут тебе поможет либо одинаковая схема для обоих частей (чёт типо xsd, например), либо тесты.

Впринципе, если у тебя ДТО чисто для одного апи ответа, ты понимаешь, что если ты его поменяешь - поменяется АПИ ответ, я думаю

Впринципе, если у тебя ДТО чисто для одного апи ответа, ты понимаешь, что если ты его поменяешь - поменяется АПИ ответ, я думаю

все так.

дальше есть вопрос - если DTO используются в одном месте, инстанцируются в одном месте - надо ли делать для этого отдельные структуры или можно скрестить это дело с мэппером если есть возможность типы отследить)))

но это опять же мои загоны

А если скрестить с мэппером, опять появятся неявные зависимости, или нет?

Что вообще это значит, скрестить с мэппером

у меня одна и та же дтошка есть в 2х разных приложениях. Она сериализуется в 1 месте и десериализуется в тот же объект в другом. просто, понятно, схема соблюдена :)

у меня одна и та же дтошка есть в 2х разных приложениях. Она сериализуется в 1 месте и десериализуется в тот же объект в другом. просто, понятно, схема соблюдена :)

Мы пытаемся их в типы тайпскрипта конвертить)

можешь посмотреть какой-нить протобаф или аналоги. Будет небольшое представление о передачи вполне формализованных вещей

Мы пытаемся их в типы тайпскрипта конвертить)

не, я не на столько наркоман

Тоже что бы убедиться что клиенту не станет плохо) но пока это все влажные мечты

Что вообще это значит, скрестить с мэппером

На предыдущем проекте я экспериментировал с fractal. Это не то что нужно но может дать представление о чем я

Я просто ленюсь переписать его так что бы оно под меня было

У меня такой вопрос, у меня есть билдер пользователя системы, который собирает данные с реквеста, базы, кук и т.д., который я пользую уже в разных частях системы. Соответствественно, сейчас через DI я внедряю VisitorBuilderInteface и уже в методе пишу detect() и получаю пользователя. Стоит ли запихивать создание этого посетителя в DIC...

нет

У меня такой вопрос, у меня есть билдер пользователя системы, который собирает данные с реквеста, базы, кук и т.д., который я пользую уже в разных частях системы. Соответствественно, сейчас через DI я внедряю VisitorBuilderInteface и уже в методе пишу detect() и получаю пользователя. Стоит ли запихивать создание этого посетителя в DIC...

метод setUser() сделай

нет

Емко, но детализируй