Структура Vue проекта

Отличная статья спасибо!

Лично я пробовал реализовать разные подохды. Но честно говоря ничего не понравилось)

В итоге на проектах всегда пишу что-то среднее между модулями и FSD.

Я full-stack разработчик и мыслю немного по другому - контрактами.

У нас должен быть контракт того что возращает нам backend (response) и мы маппим это в данные с которыми работаем внутри нашего приложения, а также данные которые мы отправляем на backend (request). Т.е. для одной сущности я часто делаю 3 класса Response, Request, Model, к ним добавляется маппер для маппинга всего этого)

А компоненты лично я распределяю так: переиспользуемые глобальные это core - ядро системы, в папке Buttons кнопки и т.д.

Если же компоненты уже страничные то в папке components по названию страницв или по содержанию логическому, к примеру Cards или Products.

Ну и конечно папки pages, stores, plugins, middleware и т.д.

Еще мне нравится в nuxt layouts но это уже другое конечно)

P.s. выше написал лично свою точку зрения)

Я сделал приложение за вечер без навыков программирования. Зачем теперь разработчики?

Ахах))

Я Разработчик, но навайбкодил такое же похожее приложение для себя, просто чтобы время не тратить)

дл создания нового окей подходит или для быстрого написания микросервисов, но вот доработать какое-нибудь легаси лучше в ручном режиме

мой проект :

https://github.com/palachX/vibe-earning?tab=readme-ov-file

Как навести порядок в запросах Laravel с помощью кастомных Query Builders

Спасибо что прочитали статью!)

В больших проетках эти усилия оправданы поверьте)

Как навести порядок в запросах Laravel с помощью кастомных Query Builders

Спасибо что прочитали статью!)

Да scope которые по дефольу есть работают хорошо, но сами понимаете в большое проекте магии laravel хочеться меньше, плюс scope могут работать медленее если посмотрите как они устроены. В примерах я показал как можно добавить фильтрацию и другие более сложные запросы. Все таки хочется больше ручногл управления.

В данных примерах нет бизнес логики, но и да писать там её не следуюет.

whereActive было бы бизнес логикой если бы было вот так:

public function whereActive()
{
    return $this
        ->whereNotNull('email_verified_at')
        ->where('status', '!=', 'blocked')
        ->whereHas('subscription', fn ($q) => $q->valid());
}

Т.е. само обозначение active. Конечно тогда такое лучше писать в других слоях приложения.

Как навести порядок в запросах Laravel с помощью кастомных Query Builders

Спасибо что прочитали статью!)

Да в laravel много магии, но как раз тут мы и хотим сделать это ручным управлением) А кастомный билдер помогает нам в этом, ведь это единая точка и любой разработчик её видит и может ей управлять)

Как навести порядок в запросах Laravel с помощью кастомных Query Builders

Спасибо что прочитали статью!)

В примерах я также описал вариант с фильирами и другими подзрапросами. whereActive только для начального прмера чтобы люди уловили идею. Да магия laravel позволяет это писать и без кастомных билдеров. Но в крупных проектах иногда хочется держать всё в ручном режиме.

Как навести порядок в запросах Laravel с помощью кастомных Query Builders

Большое спасибо, что прочитали статью!)

Конечно я показал самые базовые примеры, но то как их применить и где остается за вами!

UseCase или как описывать бизнес-процессы в коде

Спасибо что прочитали статью! Рад что есть единомышленники) Спасибо за ваш пакет, выглядит очень мощно, жаль что не встретил его раньше)

UseCase или как описывать бизнес-процессы в коде

Большое спасибо что прочитали статью!)
Полностью с вами согласен, за нас уже всё придумали)

UseCase или как описывать бизнес-процессы в коде

😂😂😂

Большое спасибо)

UseCase или как описывать бизнес-процессы в коде

Большое спасибо что прочитали статью)

Обязательно почитаю про данный подход, спасибо!)

UseCase или как описывать бизнес-процессы в коде

Спасибо, обязательно посмотрю!

UseCase или как описывать бизнес-процессы в коде

Граница между Service и UseCase действительно условна. Но цель UseCase не в строгой классификации классов. Его задача сделать структуру приложения отражением бизнес-сценариев системы.

UseCase или как описывать бизнес-процессы в коде

Большое спасибо что прочитали статью!)

1. Вы можете вынести общую логику в сервис, и сервис уже подключить в двух UseCase. Использовать один UseCase в другом UseCase лучше в самую последнюю очередь.

2. Маленькие сервисы это не UseCase. Размер класса не определяет его роль. UseCase - это один конкретный бизнес процесс, бизнес сценарий. А Service это переиспользуемая бизнес-логика, т.е. часть какого-либо сценария.

UseCase или как описывать бизнес-процессы в коде

Полностью с вами согласен!

UseCase или как описывать бизнес-процессы в коде

Понял, да конечно каждый подход надо обсуждать с командой, нужен/устраивает ли он команде/у. За-то вы знаете что умеет делать ваше приложение, могу вас обрадовать)

UseCase или как описывать бизнес-процессы в коде

Согласен с вами полностью!

Когда мы ничего не возвращаем наша архитектура становится похожа больше на команды CQRS паттерн.

Но даже самые смелые возвращают id записи чтобы была возможность у фронта обратиться за получением, либо прибегают к использованию websocket чтобы получить тот или инное событие системы.

UseCase или как описывать бизнес-процессы в коде

Большое спасибо что прочитали статью)

Если не секрет что конкретно разгребаете? С какими проблемами столкнулись?

UseCase или как описывать бизнес-процессы в коде

Большое спасибо что прочитали статью)

Не могу отрицать такие реализации тоже имеют место быть, но в данном случае мы работаем с restAPI приходиться что-то возвращать)

UseCase или как описывать бизнес-процессы в коде

Большое спасибо что прочитали)

Да UseCase-ы как оказалось уже стандарт, особенно их ценят в бигтех, так как бизнес-процессы там большие и запутаться в них легко.