Я учусь на чистой и, как следствие, довольно резко переосмысливаю, как я проектирую и пишу программное обеспечение.
Однако я по-прежнему борюсь с бизнес-правилами, такими как «сохранить обновления какого-либо элемента, сначала загрузить весь список элементов, на которые у меня есть разрешение на просмотр / редактирование и т. Д., Подтвердить, что этот элемент находится в списке, и что категория элементов в настоящее время не заблокирована для использования ((и другие правила и т. д. и т. п.) ".. потому что это (сложное, но не нетипичное) бизнес-правило, и поэтому оно должно обрабатываться в домене приложения, а не вставлять бизнес-логику в слой дб / персистентность.
Однако, мне кажется, что для эффективной проверки этих условий часто лучше всего обрабатывать красиво обработанный запрос БД, а не загружать все данные в домен приложения ...
Без преждевременной оптимизации, каков рекомендуемый подход или некоторые статьи дяди Боба, занимающиеся этим вопросом? Или он скажет: «Проверь в домене, пока это не станет проблемой» ??
Я действительно изо всех сил пытаюсь найти какие-либо хорошие примеры / образцы для чего-либо кроме самых основных вариантов использования.
Обновить:
Привет всем, спасибо за ответы. Я должен был быть более ясным, я писал программное обеспечение (в основном для веб-приложений) в течение долгого времени, и определенно уже испытал и согласился со всеми темами, которые вы коллективно описываете (проверяйте с помощью бэкенда, не доверяйте данным клиента, вообще говоря гоняться за сырой эффективностью только тогда, когда это необходимо, однако признавать сильные стороны инструментов db, когда они доступны, и т. д. и т. д.), и пройти жизненный цикл разработки для разработчиков: «собрать все вместе», чтобы «построить гигантский жирный контроллер с N-уровневыми приложениями», трендами кода и теперь действительно любит и исследует стиль чистой / единой ответственности и т. д., в основном, в результате нескольких проектов, которые недавно превратились в довольно неуклюжие и широко распространенные бизнес-правила по мере развития проектов и выявления новых требований клиентов.
В частности, я рассматриваю архитектуру чистого стиля в контексте создания API REST для клиентских и внутренних функций, где многие бизнес-правила могут быть гораздо более сложными, чем в принципе каждый пример, который вы видите в сети. (даже самими ребятами из Clean / Hex).
Так что, я думаю, я действительно спрашивал (и не смог четко указать), как Clean и API REST будут сидеть вместе, где большинство вещей MVC, которые вы видите в эти дни, имеют валидаторы входящих запросов (например, библиотеку FluentValidation в .NET), но где многие из мои "правила проверки" не так уж и много ", это строка длиной менее 50 символов", но больше "может ли этот пользователь, вызывающий этот пользовательский случай / интерактор, выполнить эту операцию с этим набором данных, учитывая, что некоторый связанный объект в настоящее время заблокирован Team X до позднего месяца и т. д. и т. д. "... те виды глубоко вовлеченных проверок, где применимо МНОЖЕСТВО объектов бизнес-домена и правил домена.
Если я раскрою эти правила в особый тип объекта-объекта Validator, который будет сопровождать каждый сценарий-интерактор (вдохновленный проектом FluentValidator, но с большим количеством бизнес-логики и доступа к данным), я должен относиться к проверке как к шлюзу, если я поместить эти проверки в шлюз (что я считаю неправильным) и т. д. и т. д.
Для справки я остановлюсь на нескольких статьях, подобных этой , но Маттиа мало обсуждает валидацию.
Но я думаю, что короткий ответ на мой вопрос очень похож на ответ, который я принял: «Это никогда не легко, и это зависит».