Десериализация сообщений и валидация
Десериализация сообщений и валидация
Передаю сообщение (сериализованное доменное событие + идентификатор) из одного контекста в другой с помощью RabbitMQ.
Нужно ли после десериализации на принимающей стороне выполнять валидацию сообщения?
На принимающей стороне есть классы, сериализованные экземпляры которых приходят в сообщениях (библиотека). Десериализовать сразу в них или это плохая практика?
Контексты могут поддерживаться разными разработчиками, проект обещает быть долгоиграющим, сообщения могут меняться со временем. Опасаюсь того, что отсутствие валидации будет приводить к непредсказуемому поведению, некорректной обработке сообщений.
Нужно ли после десериализации на принимающей стороне выполнять валидацию сообщения?
На принимающей стороне есть классы, сериализованные экземпляры которых приходят в сообщениях (библиотека). Десериализовать сразу в них или это плохая практика?
Контексты могут поддерживаться разными разработчиками, проект обещает быть долгоиграющим, сообщения могут меняться со временем. Опасаюсь того, что отсутствие валидации будет приводить к непредсказуемому поведению, некорректной обработке сообщений.
Re: Десериализация сообщений и валидация
а чем поможет валидация? Если валидация не пропустит сообщение, то доменное событие не будет обработано и система останется в неконсистентном состоянии. Разве нет?
Re: Десериализация сообщений и валидация
zelenin, мы не можем обработать невалидное сообщение, но и валидация не решает проблемы. Я думаю эта проблема формулируется гораздо шире. Изменение любого интерфейса может привести к неверному выполнению зависимого кода. Помоему для выявления подобного рода проблем используют интеграционное тестирование.
Re: Десериализация сообщений и валидация
как поможет тестирование против неверно составленного клиентом (человеком) сообщения?sda писал(а): ↑2017.04.28, 00:52 zelenin, мы не можем обработать невалидное сообщение, но и валидация не решает проблемы. Я думаю эта проблема формулируется гораздо шире. Изменение любого интерфейса может привести к неверному выполнению зависимого кода. Помоему для выявления подобного рода проблем используют интеграционное тестирование.
Re: Десериализация сообщений и валидация
zelenin, ну против человека помоему ничто не поможет, кроме ревью.
Re: Десериализация сообщений и валидация
какое ревью? у тебя есть смотрящий наружу эндпойнт - апи, консьюмер итд. Он принимает сообщения, составленные клиентом - приложением апи например или микросервисом, кинувшим сообщение в шину. Это все третьи стороны. Как выполнять их без валидации? По хорошему, все, что пришло снаружи, надо проверять.
Re: Десериализация сообщений и валидация
zelenin, ну хорошо. Провалидировали. Сообщение оказалось не валидным. Принимающая сторона не обработала доменное событие. Система остается в неконсистентном состоянии?
- slavcodev
- Сообщения: 3134
- Зарегистрирован: 2009.04.02, 21:42
- Откуда: Valencia
- Контактная информация:
Re: Десериализация сообщений и валидация
Сообщение из шины переданное другим контекстом, разве это "пришло снаружи"? При восстановлении объекта из БД ты тоже проверяешь валидность данных? БД это снаружи? Имхо тут надо четко определить что такое "данные снаружи", то что другой дев написал в отдельно разрабатываемом компоненте/микросервисе, это не третьи стороны. Данные третьей стороны это те что не подконтрольны.zelenin писал(а): ↑2017.04.28, 12:34 у тебя есть смотрящий наружу эндпойнт - апи, консьюмер итд. Он принимает сообщения, составленные клиентом - приложением апи например или микросервисом, кинувшим сообщение в шину. Это все третьи стороны. Как выполнять их без валидации? По хорошему, все, что пришло снаружи, надо проверять.
Жду Yii 3!
Re: Десериализация сообщений и валидация
slavcodev писал(а): ↑2017.04.28, 20:41Сообщение из шины переданное другим контекстом, разве это "пришло снаружи"?zelenin писал(а): ↑2017.04.28, 12:34 у тебя есть смотрящий наружу эндпойнт - апи, консьюмер итд. Он принимает сообщения, составленные клиентом - приложением апи например или микросервисом, кинувшим сообщение в шину. Это все третьи стороны. Как выполнять их без валидации? По хорошему, все, что пришло снаружи, надо проверять.
Читай, микросервисы. Внутри приложения, конечно, не надо валидировать, если есть уверенность, что оно всегда валидно.Контексты могут поддерживаться разными разработчиками,