Загрузка...

Feature-First архитектура для Laravel

Разбираем Feature-First архитектуру для Laravel и Livewire: структура проекта, правила зависимостей, примеры реализации и сравнение с классической архитектурой Laravel.
AI, Laravel 2 минуты 198

Feature-First архитектура в Laravel: как организовать растущий проект и упростить работу с AI-ассистентами

Laravel — один из самых удобных фреймворков для разработки веб-приложений на PHP. Пока проект небольшой, стандартная структура кажется почти идеальной. Файлы лежат в привычных папках, логика легко находится, а новые функции добавляются быстро.

Но проходит время. Проект растёт, появляется больше бизнес-логики, увеличивается команда разработчиков — и внезапно оказывается, что одна фича размазана по половине проекта.

Чтобы понять, как работает, например, создание брони, приходится открыть:

  • контроллер
  • FormRequest
  • сервис
  • репозиторий
  • несколько Jobs
  • Policy
  • Listener

И где-то между BookingService и BookingManager неожиданно обнаруживается баг.

Такая ситуация возникает из-за архитектуры, в которой код организован по техническим слоям, а не по бизнес-сценариям. Эту модель часто называют layer-based архитектурой.

Альтернативный подход — Feature-First архитектура, при которой код группируется вокруг бизнес-функций приложения. Такой подход становится всё более популярным в современных Laravel-проектах, особенно если разработка активно ведётся с использованием AI-ассистентов.

В этой статье разберём:

  • что такое Feature-First архитектура
  • почему стандартная структура Laravel плохо масштабируется
  • как организовать Feature-архитектуру в Laravel
  • как она сочетается с DDD, Clean Architecture и Modular Monolith
  • какие преимущества она даёт при работе с AI-ассистентами
  • как внедрить её в существующий проект

Почему стандартная структура Laravel плохо масштабируется

По умолчанию Laravel предлагает архитектуру, основанную на технических слоях.

Типичная структура выглядит примерно так:

app/
   Http/
      Controllers
      Requests
   Models
   Services
   Repositories
   Jobs
   Events
   Policies

Каждая папка отвечает за отдельный слой системы:

слой назначение
Controllers обработка HTTP-запросов
Requests валидация данных
Services бизнес-логика
Repositories работа с базой данных
Jobs фоновые задачи
Events события системы

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

Допустим, есть сценарий CreateBooking. Его код может находиться в разных местах:

Http/Controllers/BookingController.php
Http/Requests/CreateBookingRequest.php
Services/BookingService.php
Repositories/BookingRepository.php
Jobs/SendBookingEmail.php
Policies/BookingPolicy.php
Events/BookingCreated.php

Чтобы понять, как работает одна функция системы, приходится открывать файлы в разных папках.

Главная проблема layer-based архитектуры

Layer-архитектура организует код не так, как он изменяется.

Разработчики редко меняют систему по техническим слоям. Обычно изменения происходят по бизнес-сценариям.

Например:

нужно изменить правила создания брони.

В этот момент меняются:

  • валидация
  • бизнес-логика
  • модель
  • отправка уведомлений

То есть изменяется одна фича, а не один слой.

Но структура проекта заставляет разработчика искать код по всему приложению.

Что такое Feature-First архитектура

Feature-First архитектура предлагает другой подход: организовывать код вокруг бизнес-функций приложения.

Другими словами — группировать файлы по фичам.

Пример структуры:

app/
   Features/

      Scheduling/
         CreateBooking
         CancelBooking
         RescheduleBooking

Каждая папка содержит всё, что относится к конкретному сценарию.

Например:

Features/Scheduling/CreateBooking

   CreateBookingComponent.php
   CreateBookingAction.php
   CreateBookingValidator.php
   create-booking.blade.php

Теперь вся логика создания брони находится в одном месте.

Откуда появился Feature-подход

Feature-архитектура выросла из нескольких архитектурных идей.

Vertical Slice Architecture

Этот подход предполагает, что каждая операция системы представляет собой отдельный «срез» функциональности.

Например:

CreateOrder
CancelOrder
GetOrders

Каждый slice содержит всю необходимую логику:

  • validation
  • бизнес-операции
  • доступ к данным

Domain-Driven Design

DDD предлагает организовывать код вокруг доменной модели бизнеса.

Например:

Booking
Invoice
User

Feature-архитектура часто использует облегчённую версию DDD — так называемый DDD-lite.

Feature-Sliced Design

Этот подход популярен во frontend-разработке. Он также предлагает организовывать код вокруг фич.

Однако полностью переносить FSD на backend обычно не требуется.

Как выглядит Feature-архитектура в Laravel

Базовая структура проекта может выглядеть так:

app/

   Domain/
   Features/
   Shared/

   Providers

Domain слой

Domain содержит бизнес-модель системы.

Domain/

   Booking/
      Booking.php
      BookingPolicy.php
      ValueObjects/

   Invoice/
      Invoice.php

   User/
      User.php

Этот слой меняется редко и отражает предметную область приложения.

Features

Features содержит бизнес-сценарии.

Features/

   Scheduling/

      CreateBooking
      CancelBooking
      RescheduleBooking

   Billing/

      CreateInvoice
      PayInvoice

   Users/

      RegisterUser
      LoginUser

Каждая папка представляет отдельную функцию системы.

Shared

Shared содержит технические элементы, которые используются во многих местах:

Shared/

   DTO
   Enums
   Exceptions
   Support

Важно, чтобы Shared не превращался в «свалку» бизнес-логики.

Пример Feature в Laravel

Структура CreateBooking может выглядеть так:

Features/Scheduling/CreateBooking

   CreateBookingComponent.php
   CreateBookingAction.php
   CreateBookingValidator.php
   create-booking.blade.php

Livewire компонент

class CreateBookingComponent extends Component
{
    public function create()
    {
        app(CreateBookingAction::class)->handle($this->form);
    }
}

Action

class CreateBookingAction
{
    public function handle(array $data)
    {
        (new CreateBookingValidator())->validate($data);

        Booking::create($data);
    }
}

Вся логика фичи находится в одной директории.

Правила зависимостей

Чтобы архитектура оставалась чистой, важно соблюдать правила зависимостей.

Feature может зависеть от:

Feature → Domain
Feature → Shared

Feature не должна зависеть от другой Feature.

Domain может зависеть только от Shared.

Архитектура выглядит примерно так:

Features
   ↓
Domain
   ↓
Shared

Сравнение с Clean Architecture

Clean Architecture — популярный архитектурный подход, предложенный Робертом Мартином.

Она строится вокруг нескольких слоёв:

  • Entities
  • Use Cases
  • Interface Adapters
  • Frameworks

Главная идея — зависимости должны идти внутрь системы.

Плюсы Clean Architecture

  • строгая изоляция бизнес-логики
  • независимость от инфраструктуры
  • хорошая тестируемость

Минусы для Laravel проектов

На практике Clean Architecture часто приводит к большому количеству абстракций:

Interfaces
UseCases
DTO
Adapters
Repositories

В небольших и средних Laravel-проектах это может приводить к архитектуре ради архитектуры.

Feature-подход проще: он концентрируется на сценариях, а не на слоях.

Сравнение с Domain-Driven Design

DDD — это не структура папок, а подход к моделированию предметной области.

Он вводит такие понятия, как:

  • Entities
  • Value Objects
  • Aggregates
  • Repositories
  • Bounded Contexts

Feature-архитектура часто использует DDD-lite.

Domain слой содержит:

  • модели
  • value objects
  • правила домена

А Features реализуют конкретные use-case сценарии.

Таким образом, Feature-архитектура может хорошо сочетаться с DDD.

Сравнение с Modular Monolith

Modular Monolith — это монолитное приложение, разделённое на модули.

Пример:

Modules/

   Users
   Billing
   Scheduling

Каждый модуль содержит свою структуру:

Controllers
Services
Repositories
Models

Проблема в том, что внутри модуля обычно остаётся layer-архитектура.

Feature-архитектура идёт дальше — она делит систему не только по модулям, но и по сценариям.

Почему Feature-архитектура удобна для AI-ассистентов

AI-ассистенты для разработки (Copilot, GPT, Claude, Cursor) работают лучше, когда код:

  • разбит на небольшие модули
  • имеет понятные границы
  • организован по задачам

Feature-архитектура делает именно это.

AI анализирует не весь проект, а только конкретную директорию:

Features/CreateBooking

Это уменьшает контекст и повышает точность генерации кода.

Преимущества Feature-архитектуры

Простота понимания

Фича становится отдельной папкой.

Быстрая отладка

Баг локализуется внутри конкретной функции системы.

Меньше архитектурного мусора

Исчезают папки вроде:

Services
Managers
Helpers
Utils

Удобство работы с AI

AI лучше понимает use-case структуру.

Упрощение рефакторинга

Можно изменять одну фичу без риска сломать другие.

Недостатки Feature-архитектуры

Непривычная структура

Laravel-разработчики часто привыкли к layer-архитектуре.

Требует дисциплины

Если начать складывать всё в Shared, архитектура быстро деградирует.

Возможное дублирование кода

Иногда несколько фич имеют похожую логику.

Однако небольшое дублирование часто лучше, чем неправильная абстракция.

Типичные ошибки

Огромный Shared

Shared/
   Helpers
   Utils
   Managers

Это снова превращает архитектуру в layer-based.

Слишком крупные фичи

Плохо:

Features/Booking

Хорошо:

Features/CreateBooking
Features/CancelBooking

Нарушение границ зависимостей

Feature не должна напрямую использовать другую Feature.

Как внедрить Feature-архитектуру в существующий Laravel проект

Полностью переписывать приложение не нужно.

Лучший подход — Strangler Pattern.

Шаг 1

Создать новые директории:

Features
Domain
Shared

Шаг 2

Новый код писать уже в новой архитектуре.

Шаг 3

Старые фичи переносить постепенно.

Пример итоговой структуры Laravel проекта

app/

   Domain/

      Booking
      Invoice
      User

   Features/

      Scheduling/
         CreateBooking
         CancelBooking
         RescheduleBooking

      Billing/
         CreateInvoice
         RefundInvoice

      Users/
         RegisterUser
         LoginUser

   Shared/

Итог

Feature-First архитектура — один из самых практичных способов организовать растущий Laravel проект.

Она делает бизнес-логику:

  • видимой
  • изолированной
  • понятной

Кроме того, такая структура отлично подходит для разработки с AI-ассистентами, потому что код становится:

  • модульным
  • предсказуемым
  • ориентированным на конкретные сценарии.

Если приложение активно развивается, количество бизнес-логики увеличивается, а команда растёт — Feature-архитектура часто оказывается гораздо удобнее классической структуры Laravel.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *