Service Tags в Symfony: не про ивенты, а про архитектуруService tags в Symfony часто воспринимают как утилиту для Event Listener’ов и Twig-расширений. Это правда — но лишь малая часть картины. На практике
tags — один из самых мощных архитектурных инструментов Symfony, если использовать их осознанно.
Статья как раз про это: не «как повесить тег», а
как построить расширяемую систему без правок YAML и без условной логики — строго по Open-Closed Principle.
Ключевая идеяМы собираем
модульный Document Processing Pipeline:
PDF, CSV, JSON и любые новые форматы
добавление нового процессора =
новый класс, без конфигов
Symfony 7.4, PHP 8.3+, атрибуты вместо YAML
Что здесь действительно важно1. AutoconfigureTag на интерфейсеЛюбая реализация автоматически попадает в систему. Никаких
services.yaml.
2. TaggedIterator = современный StrategyТипизированная коллекция сервисов, с ключами и приоритетами, без Compiler Pass’ов «по старинке».
3. defaultIndexMethod вместо магииКлюч коллекции определяет сам сервис. Контейнер не знает доменной логики — и это правильно.
4. Кастомные атрибуты поверх теговДоменные метаданные (
type,
priority) живут в атрибуте, а не в конфиге. Код становится декларативным и читаемым.
5. TaggedLocator для ленивой загрузкиНи один процессор не создаётся, пока он реально не нужен. Это критично для больших систем.
6. Compiler Pass как архитектурный guardrailКонтейнер валидирует систему на этапе сборки:
— дубли типов
— архитектурные инварианты
— ошибки ловятся до runtime
7. Абсолютный уровень декомпозицииДаже
чистые PHP-атрибуты без зависимости от Symfony можно «подключить» через
registerAttributeForAutoconfiguration.
Домен остаётся чистым. Инфраструктура — умной.
Почему это ценно✔️ расширение без модификации
✔️ ноль условной логики
✔️ высокая тестируемость
✔️ архитектурные ошибки ловятся на этапе сборки контейнера
👉
Читать статьюБиблиотека пхпшника