Yii Framework

Передаю сообщение (сериализованное доменное событие + идентификатор) из одного контекста в другой с помощью RabbitMQ.
Нужно ли после десериализации на принимающей стороне выполнять валидацию сообщения?
На принимающей стороне есть классы, сериализованные экземпляры которых приходят в сообщениях (библиотека). Десериализовать сразу в них или это плохая практика?
Контексты могут поддерживаться разными разработчиками, проект обещает быть долгоиграющим, сообщения могут меняться со временем. Опасаюсь того, что отсутствие валидации будет приводить к непредсказуемому поведению, некорректной обработке сообщений.

а чем поможет валидация? Если валидация не пропустит сообщение, то доменное событие не будет обработано и система останется в неконсистентном состоянии. Разве нет?

sda писал(а): ↑2017.04.27, 12:08 а чем поможет валидация? Если валидация не пропустит сообщение, то доменное событие не будет обработано и система останется в неконсистентном состоянии. Разве нет?

а как мы можем обработать невалидное сообщение?

zelenin, мы не можем обработать невалидное сообщение, но и валидация не решает проблемы. Я думаю эта проблема формулируется гораздо шире. Изменение любого интерфейса может привести к неверному выполнению зависимого кода. Помоему для выявления подобного рода проблем используют интеграционное тестирование.

sda писал(а): ↑2017.04.28, 00:52 zelenin, мы не можем обработать невалидное сообщение, но и валидация не решает проблемы. Я думаю эта проблема формулируется гораздо шире. Изменение любого интерфейса может привести к неверному выполнению зависимого кода. Помоему для выявления подобного рода проблем используют интеграционное тестирование.

как поможет тестирование против неверно составленного клиентом (человеком) сообщения?

zelenin, ну против человека помоему ничто не поможет, кроме ревью.

sda писал(а): ↑2017.04.28, 12:28 zelenin, ну против человека помоему ничто не поможет, кроме ревью.

какое ревью? у тебя есть смотрящий наружу эндпойнт - апи, консьюмер итд. Он принимает сообщения, составленные клиентом - приложением апи например или микросервисом, кинувшим сообщение в шину. Это все третьи стороны. Как выполнять их без валидации? По хорошему, все, что пришло снаружи, надо проверять.

zelenin, ну хорошо. Провалидировали. Сообщение оказалось не валидным. Принимающая сторона не обработала доменное событие. Система остается в неконсистентном состоянии?

sda писал(а): ↑2017.04.28, 19:35 zelenin, ну хорошо. Провалидировали. Сообщение оказалось не валидным. Принимающая сторона не обработала доменное событие.

это факт

sda писал(а): ↑2017.04.28, 19:35Система остается в неконсистентном состоянии?

а это мне неизвестно

zelenin писал(а): ↑2017.04.28, 12:34 у тебя есть смотрящий наружу эндпойнт - апи, консьюмер итд. Он принимает сообщения, составленные клиентом - приложением апи например или микросервисом, кинувшим сообщение в шину. Это все третьи стороны. Как выполнять их без валидации? По хорошему, все, что пришло снаружи, надо проверять.

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

slavcodev писал(а): ↑2017.04.28, 20:41

zelenin писал(а): ↑2017.04.28, 12:34 у тебя есть смотрящий наружу эндпойнт - апи, консьюмер итд. Он принимает сообщения, составленные клиентом - приложением апи например или микросервисом, кинувшим сообщение в шину. Это все третьи стороны. Как выполнять их без валидации? По хорошему, все, что пришло снаружи, надо проверять.

Сообщение из шины переданное другим контекстом, разве это "пришло снаружи"?

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

Читай, микросервисы. Внутри приложения, конечно, не надо валидировать, если есть уверенность, что оно всегда валидно.