Symfony to nasz wybór, gdy projekt potrzebuje struktury klasy enterprise: ścisłej architektury, przewidywalnej ścieżki aktualizacji i komponentów czysto integrujących się z ekosystemem PHP. Sięgamy po niego do złożonych backendów, aplikacji API-first i domen zbyt bogatych dla lżejszego frameworka.
Gdzie Symfony sprawdza się najlepiej
- Backendy API-first — API Platform lub własne endpointy REST/GraphQL z jawną serializacją i wersjonowaniem.
- Złożone systemy biznesowe — fakturowanie, logistyka, platformy wieloorganizacyjne — gdzie komponenty Form, Validator i Workflow zwracają się z nawiązką.
- Długowieczne codebase'y, w których wydania LTS Symfony i obietnica kompatybilności znaczą więcej niż najnowsze funkcje.
- Samodzielne komponenty — Console, HttpClient, Messenger i EventDispatcher działają świetnie także w projektach bez Symfony.
Jak wygląda żądanie
Wszystko jest jawne: routing, walidacja i serializacja to obszar frameworka; handler trzyma logikę domeny. Praca asynchroniczna idzie przez Messenger do transportu Doctrine lub RabbitMQ.
Jak strukturyzujemy kod
Aplikacje organizujemy wokół domeny, a nie frameworka: lekkie kontrolery, jawne serwisy, uczciwe encje Doctrine, logika biznesowa testowalna bez uruchamiania kernela.
#[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();
}
}Migracja i modernizacja
Dla legacy PHP — Zend, Symfony 2/3/4 lub kod bez frameworka — migrujemy inkrementalnie: stare i nowe działają obok siebie, moduły przenosimy po jednym, biznes działa bez przerw. Opowiedz o wymaganiach — szczerze powiemy, czy lepszy będzie Symfony, Laravel czy coś innego.