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

Из обсуждения я извлек несколько тезисов:

Сущности (Entities) могут включать функциональность валидации, но только в том случае, если правила валидации максимально общие и не зависят от приложения. Например, требование поля электронной почты для подписки у сервиса почтовой рассылки.

Специфичная для приложения валидация должна осуществляться в интеракторах (Interactors) как более изменчивых объектах. Общий принцип: объекты, изменяющиеся по подобным причинам, должны быть сгруппированы вместе. И наоборот, изменяющиеся по разным причинам должны быть разделены.

При нарушении правил валидации интерактор выбрасывает исключение, задача отображения сообщений клиенту ложится на логику отображения.

Это полезно, но общо и теоретично, придется писать код, чтоб проверить на практике. Кстати, инициатор обсужения для практики по Clean Architecture пишет браузерную игру. Любопытно посмотреть код.