Eb Plantumlbundle Laravel Package

Product Decisions This Supports

• Documentation-as-artifact investment. The core value is turning "someone should draw the domain model" into a repeatable command. That makes it a real input to decisions like do we staff technical documentation, do we budget CI time for generated docs, or do we keep relying on tribal knowledge. Generated diagrams from real code are the cheapest way to test whether documentation actually gets used before you spend on it.
• Architecture and domain-model reviews. A generated class/ER diagram is a shared artifact for DDD conversations — aggregate boundaries, entity relationships, bounded contexts. Useful when scoping a refactor, a modularization effort, or a service-extraction initiative, because it shows the model as it is, not as a slide deck claims it is.
• Build vs. buy vs. wire-up. The honest comparison set is: hand-drawn diagrams (Lucidchart/draw.io), Mermaid-in-Markdown, DB-first introspection (SchemaSpy), IDE/static-analysis plugins, or this bundle. This sits in the "cheap wire-up" slot — but only if your stack already exposes Doctrine entity metadata to harvest.
• Onboarding and knowledge-transfer planning. A generated diagram reduces ramp-up time for new engineers and gives a PM a concrete artifact for architecture walkthroughs without booking a senior engineer for two hours every time.
• Roadmap hygiene / tech-debt visibility. Diffs in generated diagrams over time are a lightweight churn signal — a conversation starter for "why is this domain area changing every sprint?"
• A decision against adoption is itself cheap and valuable. This package is a reference implementation of a ~1–2 day internal script. Knowing that lets you decline a dependency without losing the capability.

When to Consider This Package

Critical gate first: despite the brief framing this as a Laravel/PHP package, it is a Symfony bundle built on Doctrine ORM metadata. It has no service providers, no facades, no Laravel autodiscovery. For a Laravel/Eloquent codebase this is a non-starter — evaluate Mermaid, SchemaSpy, or a small Eloquent-metadata script instead. Everything below applies only to Symfony + Doctrine applications.

Adopt-pilot criteria:

• Symfony application with Doctrine ORM as the source of truth for the domain model (not DB-first, not OpenAPI-first).
• You want diagrams derived from actual code and are willing to regenerate them in CI or on demand, rather than maintain them by hand.
• The team already accepts PlantUML, or is willing to add a renderer (local plantuml.jar, PlantUML server, or Kroki).
• You are running this as a time-boxed spike (≤2 days) against pinned Symfony/PHP/Doctrine versions — not a release-pipeline commitment.

Look elsewhere when:

• Stack mismatch. Laravel/Eloquent, or any project without Doctrine entity metadata.
• Adoption risk is disqualifying. Zero stars, zero dependents, score 0, no visible maintenance signal, single maintainer. If your org requires a supported dependency or a defined security-response path, this fails procurement before it reaches engineering.
• You need presentation-grade or interactive visuals. Generated PlantUML is structurally accurate and visually plain; stakeholder-facing diagrams usually still need manual layout.
• The source of truth isn't PHP entities. Database-first or spec-first models won't be seen by this tool at all.
• You need whole-application coverage. Large entity graphs produce unwieldy diagrams; value degrades fast past a few dozen entities without per-domain filtering.

Default recommendation: decline as a dependency, run a time-boxed spike or treat it as a reference implementation for a small internal generator tied to your actual stack.

How to Pitch It (Stakeholders)

To executives: This is low-cost documentation automation for the platform team — it converts existing code structure into diagrams automatically, shortening onboarding and giving us a reliable picture of the domain model during planning and refactoring discussions. Licensing and integration cost are near zero. The caveat is significant and worth stating plainly: it's a small, unmaintained, zero-adoption open-source component built for Symfony, so it is a spike candidate, not a pipeline commitment. The strategic finding is that the capability is worth ~1–2 days of internal engineering — the package is one way to get there, and probably not the way we'll keep.

To engineering: It reads Doctrine entity metadata and emits PlantUML class/relationship diagrams via a console command — no annotations to maintain, no drift between code and diagrams. Run it locally or in CI, generate into var/ (gitignored; never commit .puml or .svg — they rot and produce unreviewable diffs), and publish rendered output as a CI artifact. Two rendering paths: PlantUML server (no local Java, needs network — often blocked in CI) or local plantuml.jar -tsvg (offline, deterministic, more setup). Treat it as a dev-only documentation utility, not a runtime dependency: wrap it in a Composer script so the generator is swappable without touching application code. Before any adoption, verify compatibility against our pinned symfony/* and doctrine/orm versions — version drift is the real risk, not functionality. If it installs cleanly, decide explicitly between require-dev, vendoring/forking, or extracting the logic into an internal script and dropping the package.

To design/QA: Expect accurate structure and complete relationship coverage, but plain output. Excellent for confirming the model is understood correctly; not a substitute for curated, annotated diagrams in external communications or customer-facing material.