У меня есть REST API на основе Onion Architecture.
Но у меня есть некоторые проблемы, чтобы применить этот способ построения сервера.Конкретно с тем, каким должно быть поведение Интерфейса, если есть какие-то данные для проверки перед передачей структурированных данных в Usecase.
Это одна из моих проблем:
У меня есть несколько методов в интерфейсе, которые получают информацию о таймерах из запроса.Но я всегда сталкиваюсь с одним и тем же вопросом.Должен ли я поймать все и передать в Usecase и выполнить все проверки там, или вместо этого, сначала я должен проверить, существует ли таймер в БД (если я обновляю таймер), и после этого делать то, что мне нужно?
Этот тип проверок, например, Роль того, кто запрашивает, и что разрешено делать или нет, если существуют таймеры, если пользователь существует, если пользователь уже существует, и вы не можете создать кого-то с тем же именем пользователя (яхотите ограничить уникальное имя пользователя) и т. д., меня раздражают, потому что в зависимости от того, где я делаю проверку, строго следуя Onion Architecture или нет, я выполняю больше или меньше кода, который иногда не нужен.
ЕслиЯ проверяю некоторые вещи в интерфейсе, я избегаю выполнения кода, который был бы излишним.Но я не правильно следую этой Архитектуре, и наоборот.
Есть мысли?