Wofür wir Symfony einsetzen
Symfony kommt dann zum Einsatz, wenn ein Prozess sich nicht in ein Standardsystem biegen lässt. Das sind Kundenportale mit eigenen Rollen und Freigaben, Verwaltungsoberflächen für Fachabteilungen, Buchungs- und Antragsstrecken oder Verarbeitungsstrecken, die Daten aus mehreren Quellen zusammenführen. Häufig steht am Ende eine API, die ein Shop, eine App oder ein Partnersystem nutzt. Der Auslöser ist fast immer ein Prozess, den heute jemand von Hand in Excel zusammenhält.
Der zweite Bereich ist Shopware 6. Der Shop bringt Symfony mit, also gelten dort dieselben Regeln: Dependency Injection, Events, Bundles beziehungsweise Plugins. Wer das Framework kennt, muss sich bei einer Shopware-Erweiterung nicht auf Dokumentation verlassen, sondern kann im Code nachsehen, was tatsächlich passiert. Das ist der Grund, warum Shopware-Projekte und Individualentwicklung bei uns nicht in getrennten Teams landen.
Wie wir mit Symfony arbeiten
Datenbankzugriffe laufen über Doctrine, Hintergrundarbeit über Messenger mit einer Warteschlange, wiederkehrende Aufgaben über Console-Commands. Berechtigungen regelt die Security-Komponente mit Votern statt mit verstreuten Abfragen, Eingaben prüft der Validator an einer Stelle. Das klingt nach Bürokratie, spart aber genau die Diskussionen, die in gewachsenen Projekten Zeit kosten: Wo gehört das hin, und wer darf das eigentlich sehen.
Wir arbeiten bevorzugt auf den LTS-Versionen, weil ein Projekt, das jahrelang läuft, keine halbjährlichen Zwangsumbauten braucht. Upgrades bereiten wir mit Rector und PHPStan vor, statt sie von Hand zu suchen. Entwicklung und Betrieb laufen in Docker, Deployments über eine Pipeline mit automatisierten Tests. Für Suche und Zwischenspeicher kommen Elasticsearch und Redis dazu, betrieben auf unseren Servern in Deutschland.
Grenzen und Alternativen
Symfony ist kein CMS und kein Shopsystem. Wer eine Website mit Redaktion braucht, bekommt mit TYPO3 oder WordPress schneller ein besseres Ergebnis, und wer verkaufen will, ist mit Shopware 6 besser bedient als mit einem selbst gebauten Warenkorb. Ein eigener Shop auf Symfony bedeutet, Zahlungsarten, Steuerlogik, Retouren und Rechtstexte selbst zu pflegen — dauerhaft, nicht einmal zum Start.
Auch nach unten gibt es eine Grenze. Für ein Formular mit Mailversand oder ein kleines Tool ist ein volles Framework Ballast; da reicht deutlich weniger. Und Symfony verlangt Disziplin: Ohne Kenntnis von Dependency Injection und Doctrine entsteht schnell etwas, das aussieht wie Symfony und sich verhält wie ein Skript von 2009. Individualsoftware rechnet sich, wenn der Prozess das Geschäft trägt — sonst nicht.