Doctrine Yuml Bundle Laravel Package

Product Decisions This Supports

• Onboarding and architecture documentation. Auto-generates entity-relationship diagrams from Doctrine mapping metadata, giving new engineers a "here is the actual data model" artifact without hand-drawing it. Decision supported: invest in docs-as-code vs. rely on tribal knowledge.
• Pre-refactor and migration risk assessment. Visualize associations, inheritance, and embeddables before splitting a monolith, extracting a service, or changing a schema. Supports go/no-go on data-model changes by exposing hidden coupling.
• Build vs. buy (adopt) for tooling. Metadata-to-diagram-DSL is a few hundred lines of glue — not worth building in-house, and cheap to adopt. But it is equally not worth a large investment given mature alternatives, so frame it as a low-cost experiment, not a platform choice.
• Roadmap signal. Repeated need for this tool indicates the domain model is under-documented; the durable roadmap item is a CI-generated diagram pipeline, not this specific dependency.
• Scope check. This is a Symfony bundle on top of Doctrine ORM — it is not a Laravel/Eloquent package. In a Laravel codebase the decision is "do we run Doctrine at all," which is a much larger architectural call than a diagram tool should drive.
• Not customer-facing. Business case is engineer-hours saved and reduced change risk; do not put it on a product roadmap as a feature.

When to Consider This Package

Consider it when:

• The codebase is a Symfony application with Doctrine ORM entities (the package registers as a bundle and exposes a console command).
• You need a fast, disposable visual — a diagram in a PR description, spike doc, or wiki page — rather than a governed, versioned artifact.
• You only need the generated yuml markup and are indifferent to the rendering service, or you are willing to accept yuml.me as a third-party rendering dependency.
• The team accepts the maintenance profile: 41 stars, 0 known dependents, no community validation. Pin the version, keep it in require-dev, and assume you own any fixes.
• A half-day spike confirms output fidelity on your largest entity graph (inheritance, embeddables, bidirectional associations, multiple connections).

Look elsewhere when:

• You need a maintained or supported dependency, or anything on a production/runtime path.
• You need CI-integrated, versioned diagrams — PlantUML, Mermaid, dbdiagram.io, or reverse-engineering from a live schema are safer, more durable renderers.
• You are on Laravel/Eloquent; use relationship introspection or a DB reverse-engineering tool instead of introducing Doctrine.
• Security or licensing review flags abandoned packages or external image rendering.
• Your model is large or inheritance-heavy and a spike shows the diagrams misrepresent it — a wrong diagram is worse than none.

How to Pitch It (Stakeholders)

Executives: A free, small internal utility that turns our database entity definitions into diagrams automatically, saving engineering hours during onboarding and before schema refactors. Cost and risk are low, it has no customer-facing impact, and it never ships to production. It is also low strategic value and sits on a lightly maintained package plus an external rendering service — so treat it as a scoped experiment with a clear fallback, not a platform commitment.

Engineering: Drop-in Symfony bundle that reads Doctrine metadata and emits yuml markup — useful for answering "what is our data model, really" in legacy apps. It is dev-only (require-dev), ~41 stars with zero known dependents, so we vendor-pin and own any patches. Before adopting, spend half a day: install it, render our largest entity graph, and check fidelity on inheritance, embeddables, and associations, plus whether yuml.me renders reliably. If either check fails, generate PlantUML or Mermaid from the same metadata or from the schema — the deliverable is the diagram pipeline, not this bundle, so the tool choice must not block the outcome.