User Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the identity/user domain. msgphp/user-bundle is a reference implementation of a decoupled User domain (entities, repositories, register/change-password style commands, domain events) rather than a full auth stack. It informs the "build vs. borrow" call for registration, profile, and credential lifecycle — but the answer it supports here is borrow the patterns, not the code.
• Roadmap sequencing for account flows. The bundle's command/event model maps cleanly to milestones (register → verify → authenticate → manage profile → deactivate). Useful for scoping an MVP identity epic before committing to a framework-native solution.
• Architecture decision: framework-coupled auth vs. isolated domain. It demonstrates keeping the user domain independent of the web framework, so identity logic survives framework upgrades or a future service split. That's a real roadmap hedge for products expecting to outgrow a monolith.
• Use cases it fits. Early-stage back-office tools, internal admin systems, or prototypes on Symfony + Doctrine where a small, event-sourced user core is enough and no compliance/SLA burden exists.
• A decision it should not drive. The prompt frames this as a Laravel/PHP package; it is a Symfony bundle built on the msgphp ecosystem (Doctrine, command bus). It is not a Laravel package and offers no Laravel integration. For a Laravel roadmap, the equivalent decisions are served by Fortify, Breeze, Jetstream, Sanctum, and spatie/laravel-permission — this package is out of scope.

When to Consider This Package

Adopt only under a narrow set of conditions, all of which must hold:

• The stack is Symfony + Doctrine, not Laravel.
• The team is already invested in the msgphp family (domain, doctrine, user) and accepts the shared abstractions and upgrade coupling.
• The product needs a minimal user domain — registration, credential handling, basic roles — with no requirement for social login, MFA, SSO, or a packaged UI.
• You are comfortable owning the code: forking, patching, and auditing it internally.

Look elsewhere if any of the following apply — and for most teams, several will:

• You're on Laravel. There is no integration path; using this means porting the domain by hand, which defeats the purpose.
• You need maintained, security-reviewed auth. With ~2 stars, 0 dependents, and a low opportunity score, this has effectively no community, no downstream validation, and no visible security response process. Authentication is a security-sensitive surface; unmaintained code there is a liability, not a shortcut.
• You need support, SLAs, or a hiring pool. No ecosystem means no Stack Overflow answers and no engineers who've seen it.
• You need features beyond the basics — MFA, OAuth, passkeys, audit logging, compliance reporting. You'd be building them anyway, on an unsupported base.

Recommendation: treat this as a design reference, not a dependency. Read the command/event structure, lift the separation-of-concerns ideas, and implement on a maintained foundation.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed reference library for modeling the user/account domain. It is not a supported product and not a fit for our stack — it is a Symfony component and we are on Laravel. The value is architectural: it shows a clean way to keep identity logic isolated from the framework. My recommendation is not to add it as a dependency; instead we adopt the pattern on top of a maintained, security-reviewed foundation. Net effect on the roadmap: a small design-spike cost now, avoided maintenance and security risk later.

To engineering: Read it for the bounded-context shape — User as a domain object, registration and credential changes as commands, state changes as events, persistence behind repositories. Do not take it as a dependency: it's Symfony/Doctrine/msgphp-specific, has essentially zero adoption, and sits directly on our most security-sensitive surface. If we want this separation, we implement it against Laravel's native primitives (Fortify for flows, Sanctum for tokens, an event/command layer of our own) so we keep patch coverage and a hiring pool.

Bottom line for the decision log: evaluated and rejected as a dependency; accepted as an internal design reference. Revisit only if we move to Symfony or the msgphp ecosystem gains meaningful maintenance and adoption.