Symfony — наш вибір, коли проєкту потрібна enterprise-структура: чітка архітектура, передбачуваний шлях оновлень і компоненти, що чисто інтегруються з PHP-екосистемою. Ми беремо його для складних бекендів, API-first застосунків і доменів, занадто насичених для легшого фреймворку.
Де Symfony підходить найкраще
- API-first бекенди — API Platform або власні REST/GraphQL-ендпоінти з явною серіалізацією та версіонуванням.
- Складні бізнес-системи — інвойси, логістика, мультиорганізаційні платформи — де компоненти Form, Validator і Workflow окупають себе.
- Довгоживучі кодові бази, де LTS-релізи Symfony й обіцянка зворотної сумісності важливіші за нові фічі.
- Окремі компоненти — Console, HttpClient, Messenger та EventDispatcher чудово працюють і в не-Symfony проєктах.
Як виглядає запит
Все явно: роутинг, валідація й серіалізація — зона фреймворку; хендлер тримає доменну логіку. Асинхронна робота йде через Messenger у транспорт Doctrine або RabbitMQ.
Як ми структуруємо код
Застосунки організовані навколо домену, а не фреймворку: тонкі контролери, явні сервіси, чесні Doctrine-сутності, бізнес-логіка, що тестується без запуску ядра застосунку.
#[AsMessageHandler]
final class GenerateInvoiceHandler
{
public function __construct(
private InvoiceRepository $invoices,
private PdfRenderer $pdf,
) {}
public function __invoke(GenerateInvoice $command): void
{
$invoice = $this->invoices->get($command->invoiceId);
$this->pdf->render($invoice);
$invoice->markGenerated();
}
}Міграція та модернізація
Для legacy PHP — Zend, Symfony 2/3/4 або код без фреймворку — ми мігруємо інкрементально: старе й нове працюють поруч, модулі переносяться по одному, бізнес працює без зупинок. Поділіться вимогами — чесно скажемо, що підійде краще: Symfony, Laravel чи щось інше.