Symfony Aop Doctrine Bundle Laravel Package

Getting Started

tourze/symfony-aop-doctrine-bundle is a Symfony bundle, not a Laravel package — there is no service provider, no config/*.php to publish, and no php artisan surface. It wires Tourze's AOP layer (tourze/aop) into Doctrine so that calls on Doctrine-backed services/repositories can be intercepted by aspects. As a Laravel developer you'll typically meet it in one of three situations: a Doctrine-based sub-application embedded in a Laravel app, a migration off Symfony, or as a reference implementation for the same pattern using Laravel's container decorators.

Steps to get oriented:

1. composer require tourze/symfony-aop-doctrine-bundle:^1.0 and read the emitted composer.json constraints — the real contract is PHP version, symfony/* major, doctrine/orm/doctrine/doctrine-bundle, and tourze/aop. Those constraints tell you more about compatibility than the release notes do.
2. Read three files first, in this order: the bundle class (what it registers), the DependencyInjection/*Extension.php (what services/config it defines), and the CompilerPass (where weaving/proxying is actually hooked into Doctrine). The compiler pass is the heart of the package and the file you'll debug against.
3. Register the bundle in bundles.php (or your minimal Symfony kernel). Ordering matters relative to DoctrineBundle, since the pass needs Doctrine's metadata/proxy services to exist.
4. First use case: put an aspect on a single repository method (audit logging or a retry wrapper are the cheapest to verify), call it from a console command or a kernel-booting test, and confirm the interceptor fires. Don't start with entity lifecycle interception — start with one repository method so failures are unambiguous.

If you're staying pure Laravel, this bundle will not drop in. You'd either use tourze/aop directly with a hand-rolled container decorator, or wrap repository calls in a middleware/decorator pattern instead.

Implementation Patterns

• Aspect-per-concern on repositories. The idiomatic shape here is: plain Doctrine repository, aspect class holding the cross-cutting behaviour (transaction demarcation, retry, cache read-through, audit trail), and the bundle's weaving connecting them. Keep business logic out of the aspect; keep the repository free of infrastructure concerns.
• Tag-and-priority. Aspects are registered via container tags, and multiple aspects on the same join point are ordered by priority. Model this explicitly — a caching aspect must sit outside an audit aspect, or you'll log cache hits as real work.
• Scope pointcuts tightly. Target named repository/service methods, not namespaces or "all public methods." Broad pointcuts are how this pattern turns into a debugging nightmare.
• Decorate services rather than entities. Intercepting service/repository calls is cheap and predictable; intercepting entity getters/setters runs inside Doctrine's hydration loop and is a performance trap.
• Cache the woven output like any compiled container artefact. Build it in CI or at deploy time, ship it, and keep the same cache key across app servers.
• Testing. Two layers: unit-test the aspect class directly against a stub invocation (fast, no kernel), and one functional test that boots the kernel and asserts interception actually happens for a given method. The latter is the only test that catches a mis-scoped pointcut or an unregistered pass.
• Integration tip for Laravel-adjacent codebases: if you're bridging, expose the intercepted repositories behind interfaces your Laravel code already depends on, so the Symfony container stays at the boundary and doesn't leak into controllers/jobs.

Gotchas and Tips

• 1.0.1 is a patch with no published notes. The only changelog entry is a 1.0.0...1.0.1 compare link. Pin 1.0.1 exactly, and run composer diff/the GitHub compare before upgrading anything else — you cannot infer the change surface from the version number alone.
• No Laravel affordances. Don't look for vendor:publish, facades, or config merging. Any configuration is Symfony bundle config under the bundle's root key in config/packages/*.yaml.
• Stale proxies after deploy. AOP/Doctrine proxy caches are the number-one source of "my aspect doesn't fire in prod but works locally." Clear and rebuild the cache as part of the release step, not on first request.
• Silent non-interception. final classes, private/static methods, and methods called via self::/new bypass weaving. Nothing throws — the aspect simply never runs. When an aspect "isn't working," check these before checking the container.
• Bundle ordering versus DoctrineBundle. If your compiler pass runs before Doctrine's, the metadata services aren't there and you get a container-build exception rather than a useful message. Register the bundle after Doctrine in bundles.php.
• Debugging toolkit: bin/console debug:container --tag=<aspect-tag> to confirm your aspects are tagged, debug:container <service> to confirm the service is decorated, and bin/console cache:clear between attempts — container changes are invisible without a rebuild.
• Performance budget. Measure before and after adding an aspect to anything on a hot path. Interception adds a proxy hop per call; on high-frequency repository calls it compounds quickly.
• Extension points to know: custom compiler passes (to add your own tagged aspects), the aspect/interceptor tag names in the bundle's extension, and the aspect registry service — these three are the sanctioned seams. Avoid patching the bundle's DI classes; you'll lose that work on the next patch release.

Caveat: this assessment is based on the package name, its Symfony/Doctrine/AOP dependency surface, and the 1.0.1 release (which carries no descriptive notes). Verify tag names, config keys, and minimum Symfony/Doctrine versions against the installed composer.json and the bundle's DependencyInjection directory before relying on them.