День 1357. #ЗаметкиНаПолях #DDD Маппинг Ошибок. Чья Это Ответственность? Допустим, модель предметной области возвращает ошибку, о которой нельзя сообщать пользователю, поэтому её нужно смаппить в дружелюбное пользователю сообщение или просто очистить от конфиденциальных данных. Должно ли это происходить на уровне домена или в контроллере (на прикладном уровне)? Кажется, что «чище» поместить этот код в контроллер, так как это зона ответственности контроллера. С другой стороны, это похоже на проблему домена. Это довольно типичный случай. Самый распространенный пример: приложение проверяет имя пользователя и пароль при входе в систему. В этом сценарии может быть несколько ошибок проверки, в том числе: - пользователь не найден в базе; - имя пользователя не соответствует основным правилам проверки (например, оно слишком короткое); - пароль неверный и т.д. Из соображений безопасности вы не можете отобразить пользователю точную ошибку проверки. Все, что вы можете показать, это что-то обобщённое: «Имя пользователя или пароль неверны». Где должно происходить сопоставление конкретной ошибки с обобщённым сообщением? На уровне домена или приложения? Это должно происходить на уровне домена. Маппинг/очистка сообщения об ошибке является проблемой предметной области. Это исходит из бизнес-требований, что означает, что должно быть частью домена. Введите отдельный класс предметной области, такой как ErrorMapper, ErrorCleaner или что-то подобное. Это не только поставит логику на место, но также упростит контроллер и улучшит тестируемость: намного проще создать модульный тест метода, возвращающего ошибку и маппинга ошибок, чем тестировать целый контроллер, работающий с несколькими внепроцессными зависимостями. Это, кстати, суть паттерна Humble Object. Идея состоит в том, чтобы извлечь важную часть логики (маппер ошибок) из контроллеров, чтобы упростить модульное тестирование этой логики. Источник: https://khorikov.org/posts/2022-02-28-error-mapping/