Валидация приходящих в приложение данных это то, на чем часто заканчивается вся красота и строгость архитектуры и начинается мешанина представления и бизнес-логики. Правила валидации зачастую содержат информацию о структуре Сущностей (в терминах Clean Architecture из прошлого поста), например, что поле e-mail обязательно. Нередко они говорят о каких-то частных особенностях данных, например, для обычных юзеров можно создать не более десяти счетов, а для премиумных ограничения нет. Наконец, какие-то особенности представления: формат номера телефона, кредитной карты и т.д. Добавить к этому выдачу клиенту сообщения об ошибке - вот и нанесен удар нашему чувству прекрасного. Фреймворки по-разному решают проблему организации валидации, мне стало интересно, что с этим делать в рамках Clean Architecture с ее жесткой изоляцией слоев. Довольно быстро нагуглилась ветка из Гуглогрупп (группы, посвященные обсуждению методики, здесь), где в обсуждении принял участие Uncle Bob.
Из обсуждения я извлек несколько тезисов:
Это полезно, но общо и теоретично, придется писать код, чтоб проверить на практике. Кстати, инициатор обсужения для практики по Clean Architecture пишет браузерную игру. Любопытно посмотреть код.
