от данных полученных от кастомера или сторонней системы. Ты же реквесты / респонсы мапишь на свои структурки?
По хорошему, в контексте ты описываешь интерфейс, например,
getUserInfo(int $id): UserInfo
При этом UserInfo это структурка этого же контекста.
В инфраструктуре своего контекста делаешь адаптер, который маппит ответ какого-то юзер контекста на эту структуру.
Надо ли тебе UserId прямо как VO внутри этой структуры? Зачем? Ну если надо - пишешь свой и в адаптере респонс мапишь на свою внутреннюю VOху
Там есть одна опасность - у тебя вот в сообщении ты общаешь на все данные В целом это все не важно. Важно что между контекста и количество взаимодействий и "что ты передаешь" надо ограничивать. Меньше лучше. Что до типов - нет ничего плохого в том что бы был общий модуль с контрактами если стэк технологий позволяет. А в целом можно мысленно представить что все контексты - независимые микросервисы и все написаны на разных языках. Просто что бы было проще представить себе весь этот треш
Этот общий технический шаред кернел во первых начинает пухнуть безбожно, а во вторых становится адской проблемой в ситуациях типа "а вот тут задачка подъехала, но на пхп мы её не решим, нужно брать ноду/го/джавку/етс И приходится дублировать этот шаред кернел в разные языки, держать из синхронными и вот это вот все
> И приходится дублировать этот шаред кернел в разные языки, держать из синхронными и вот это вот все А разве если делать для каждого контекста отдельную структуру, то это не приходиться делать? В смысле, мол при изменении контракта нужно и маппер/нормалайзер допиливать.
Не делай breaking changes по возможности. Если в респонс добавилось новое поле, но тебе оно не нужно в другом контексте, то и не мапь его. Ну и чутка магии не помешает. Полно готовых либ которые один объект на другой сами замапят
Если их не делать, то и с синхронизацией в других языках попроще будет. Но, в любом случае, один раз поправить маппер проще, чем править в множестве мест, где ранее "общая" структура использовалась
Обсуждают сегодня