Doctrine Discriminator Bundle Laravel Package

Product Decisions This Supports

What this actually touches — and what it doesn't

• Not a product feature. levelab/doctrine-discriminator-bundle is developer tooling for Symfony + Doctrine ORM. It has no user-facing surface, no monetization lever, and no competitive angle. It belongs in engineering-day budgeting, not on a roadmap.
• It informs one architecture decision: how polymorphic entity types are registered. Doctrine's single-table inheritance requires a discriminatorMap declared centrally on the root entity — one array listing every subclass. That makes the root a shared mutable registry that every squad must edit to add an order type, payment method, notification channel, or workflow step. This bundle inverts the direction: each subclass declares its own discriminator value and the map is synthesized at metadata-load time. The PM-relevant consequence is the marginal cost of adding a new business object type, which is exactly the kind of cost that quietly gates roadmap sequencing.
• It informs build-vs-buy-vs-skip. Three real options: (a) adopt the bundle, (b) reimplement the pattern in-house (~150–250 lines, 1–2 engineering days), (c) leave the explicit map alone. Cost of (c) is essentially zero below ~5 subclasses; it scales with headcount and edit-conflict frequency, not with entity count alone.
• It informs team-scaling and code-ownership. A centralized discriminator map is a coordination tax: one file, many owners, recurring merge conflicts, review bottlenecks. Decentralizing is a coordination-cost decision as much as a technical one — and that is the strongest PM-legible argument available here.
• Where it feeds a genuine product requirement: if the roadmap includes third-party, tenant-specific, or plugin-registered entity subtypes that must be added without patching core, this pattern is the enabling mechanism. If that requirement doesn't exist, the package is solving a problem you don't have.

Verdict signal: the high opportunity score reflects a real underlying problem, not a ready artifact. This is a pattern decision, not a product decision — and the shipped implementation is a 2016-era Symfony bundle (12 stars, 0 dependents, no release since March 2016).

When to Consider This Package

Consider the pattern (rarely the dependency) when:

• You are on Symfony + Doctrine ORM with single-table inheritance. This is the hard gate. Despite Laravel/PHP framing in the request, this is a Symfony bundle built on Doctrine metadata drivers. It does not apply to Eloquent, and Eloquent has no discriminator concept — Laravel shops should stop reading here.
• You have roughly 6+ subclasses of one entity spread across multiple bundles or packages, and the root entity's discriminator map has become a merge-conflict hotspot or an accidental coupling point between teams.
• You need modular or third-party extension — tenants or plugins register their own entity subtypes without touching core.
• You accept the honest play: read the package's metadata listener and reimplement it internally (~1–2 days), rather than composer require it.
• You have verified the target PHP and Doctrine ORM versions. Doctrine 3 and PHP 8 attributes make 2016 annotation-era code fragile; the reimplementation should use a PHP 8 attribute and drop doctrine/annotations entirely.

Look elsewhere or skip when:

• You're on Laravel/Eloquent — no Doctrine, no discriminator map, no relevance. Installing it would drag a parallel Symfony kernel in for zero benefit.
• You have fewer than ~5 subclasses. The explicit map is clearer, greppable, and carries no dependency risk. Don't optimize a file that changes twice a year.
• You need a maintained dependency. Last release 2016-03-03, 12 stars, 0 dependents, small single maintainer org, no CI signal, no security process, no upgrade path. Treat this as source material, not a dependency.
• You use Class Table Inheritance, or an enum + factory / strategy pattern instead of STI. STI is frequently the wrong call for wide schemas with subtype-specific columns.
• Discoverability matters more than edit-conflict reduction. Decentralized maps trade one greppable array for "the map is everywhere." Make that trade deliberately — and ship a build-time assertion enumerating all resolved subtypes so there's still one place to read the full map.
• Your Composer or security policy blocks unmaintained packages — and most enterprise setups do.

Adoption gate: require (1) a named engineering owner willing to fork or reimplement, (2) confirmed Symfony/Doctrine version fit, (3) a written note on what happens when the fork drifts. Absent all three, default to "implement the pattern internally" or "defer."

How to Pitch It (Stakeholders)

To executives — one paragraph: "This is a small developer-productivity decision, not a product feature. Our entity model funnels every team through a single shared file whenever we add a new business object type — that file is a coordination tax and a merge-conflict source that grows with headcount. An open-source package removes that bottleneck by letting each subtype describe itself. It's free (MIT), but it has been unmaintained since 2016 with negligible adoption, so the recommendation is to adopt the pattern, not the dependency: roughly one to two engineering days to implement in-house, zero licensing cost, and it directly reduces cross-team friction as we add entity types next year. Low cost, low risk, modest but real payoff. Not worth a roadmap line; worth an engineering day."

To engineering leads:

• The problem is real and Doctrine-idiomatic: move discriminatorMap responsibility from the root entity to subclasses via a metadata subscriber, so adding a subtype means touching exactly one new file and zero existing ones.
• The package is a reference implementation, not a dependency: 12 stars, 0 dependents, last release 2016, no CI or security posture, and the reuseable core is welded to HttpKernel\Bundle and a DI extension. Read it, port it, own it.
• Concrete shape: a Doctrine\Common\EventSubscriber on loadClassMetadata that discovers subclasses carrying #[DiscriminatorValue('foo')] and assigns discriminatorMap/subClasses. Register it via the laravel-doctrine config or the ORM event manager — no bundle class required. Cache the discovered map with a deploy-stamped build ID and warm it post-deploy; never scan at request time.
• Guardrail: decentralized maps reduce discoverability. Ship a test asserting the resolved map matches an explicit fixture map, plus a test proving a subclass in a new package is picked up without editing the root.
• Risk note: metadata-layer interception is the highest-blast-radius place to inherit risk — failures surface as hydration and data-integrity bugs, not clean crashes. First-party code with tests converts that into a controlled surface.
• Explicitly out of scope for Laravel/Eloquent services.

To the requesting team (ask):

• Confirm stack and versions before we commit: Symfony + Doctrine ORM, and the Doctrine major (Doctrine 3 / PHP 8 means reimplement, not integrate).
• Bring two numbers: current subclass count, and how many teams have edited the root entity this quarter. Under ~5 subclasses or a single team, we defer and revisit when conflict rate justifies it.
• Clarify the goal: is it removing coupling from the base entity (a style preference), or letting external/plugin packages register subclasses without patching core (a legitimate product requirement)? Only the second one earns engineering time on its own.