Laravel Domain Oriented Laravel Package

Technical Evaluation

Architecture fit adhenrique/laravel-domain-oriented is a convention scaffold, not an infrastructure component. From the released surface (domain-scoped service providers, Resource classes, a ValidateService exposing getRules(), Artisan generators for new domains, auto-discovery of per-domain routes/migrations/providers), it encodes a DDD-lite modular-monolith layout: one namespace per bounded context, each owning its controllers, models, services, events, routes and migrations. That maps onto Laravel primitives the framework already provides — the service container, package discovery, Form-Request-style validation, API Resources. The package contributes an opinion about where files live and what base classes they extend, not a runtime engine. Fit is therefore high for teams already thinking in domains, neutral for teams on a traditional app/Http/Controllers layout where it implies a refactor, and poor where the team lacks domain-boundary experience — the package helps you place a bounded context but does nothing to help you decide what one is.

Integration feasibility Installing is a composer require plus publish/register of providers, but the real feasibility gate is version alignment. The last release is January 2022, placing it in the Laravel 8/9, PHP 7.4–8.1 window. There is no evidence of Laravel 10/11/12 support, and with 11 stars and 0 dependents there is no downstream ecosystem pressure to keep it current. Practically this is a fork-or-vendor decision, not a composer require decision. Because the surface is small and MIT-licensed, vendoring the base classes and stubs into app/Domain/Support is a low-effort path that preserves the authoring conventions while eliminating the dependency.

Technical risk

• Abandonment: ~3.5 years without a release, single maintainer, low bus factor, no observable security or CVE process.
• Version drift: high likelihood of incompatibility with current Laravel; the package is effectively two to three majors behind Laravel's cadence.
• Release-discipline signal: v2.1.1 is labelled a patch yet fixes a Resource field-name typo (potentially breaking for anyone serializing that field) alongside widening ValidateService::getRules() to public. Widening visibility is safe; shipping a field rename in a patch indicates loose semantic versioning — a direct input to future upgrade-cost estimates.
• Adoption risk: 0 dependents means no field-tested edge cases, no community corpus to search, and no peer validation of the abstraction.
• Low blast radius: the abstraction is thin, so worst case is bounded — you inherit a directory convention and a handful of base classes, not a framework.

Key questions

1. What Laravel/PHP versions does composer.json actually constrain, and does it install cleanly on our target runtime?
2. Is there a test suite, and does CI exercise the base classes or only lint?
3. Does the package own any container bindings or global behavior (middleware, exception handling, route loading) that would make removal non-trivial?
4. Which base classes must an application class extend, and what is the coupling cost of abandoning them later?
5. Does the abstraction earn its keep versus Laravel-native app/Domain/{Context} with plain service providers and Form Requests?
6. Who owns the fork internally if we adopt it, and what is the removal plan if the convention erodes?

Integration Approach

Stack fit Suitable only for a Laravel 8/9 estate on PHP ≤8.1. On Laravel 10+ the practical posture is to treat the repository as reference material and port the pattern rather than the package. The pattern itself — namespaced domains, per-domain providers, dedicated validation services, API Resources — is version-agnostic and survives Laravel upgrades without any third-party code in the tree.

Migration path Recommend pattern adoption, not package adoption:

1. Spike (one sprint-week): install in a throwaway Laravel app matching our version, exercise the generator → provider → validation → resource flow, and document precisely what the package contributes over vanilla Laravel.
2. Internalize: copy base classes and stubs into our own app/Domain/Support namespace under our coding standards, PHP constraints, and test harness. MIT permits this with attribution.
3. Pilot: apply the convention to one non-critical bounded context (e.g., notifications or billing read-models) for one or two sprints; measure onboarding time and boilerplate delta against the current layout.
4. Decide: promote to a documented ADR or discard. Never a big-bang restructure — existing controllers migrate opportunistically as domains are touched.

Compatibility Watch PSR-4 autoload mapping, package auto-discovery, and any published config or stub paths. If we vendor, we remove auto-discovery entirely and register providers explicitly — preferable for auditability. Confirm no class-name collisions against an existing App\Domain\* or Resource namespace before the pilot begins.

Sequencing Spike → fork/vendor → ADR → single-context pilot → rollout by context. The fork decision must be made before the next Laravel major upgrade, not during it.

Operational Impact

Maintenance Near-zero if vendored (a few hundred lines of base classes and stubs); unmanageable if consumed upstream, because we would inherit an unowned dependency with no upgrade path. Budget roughly 2–5 engineer-days per year for a vendored fork, concentrated in Laravel major-upgrade windows. Treat the upstream repository as archived.

Support No commercial support, no maintainer responsiveness guarantee, no security disclosure channel. Internal ownership is mandatory: a named team owns the base classes, the stubs, and the ADR. Onboarding documentation must be written by us — the package ships effectively a two-line description plus a changelog.

Scaling The package does nothing for runtime scaling; its value is organizational — reducing cross-domain coupling and making ownership boundaries legible as headcount and context count grow. That value is delivered by the convention, not the code, and enforceability is weak: nothing prevents a developer from bypassing base classes or reaching across domains. Pair adoption with static analysis (PHPStan, deptrac) or the convention will erode within two quarters.

Failure modes

• Silent divergence: developers bypass ValidateService or the base Resource, creating two validation paths per domain with no guardrail in the package.
• Semver surprise: a future patch renames a field again and breaks serialized API output.
• Upgrade cliff: consuming upstream on Laravel 9 blocks the eventual Laravel 10/11 upgrade; the fork decision must precede that upgrade.
• Namespace collision between the package's Domain/Resource conventions and existing app code.
• Low-signal dependency: with 0 dependents, defects surface in our production first, with no peer precedent to search.

Ramp-up Low for Laravel-fluent engineers — roughly half a day to learn the convention. Moderate for teams new to domain boundaries, because the harder skill is deciding what a bounded context is, which the package does not address. Expect a 1–2 week productivity dip per engineer during the first domain they own.

TPM recommendation The 0.515 quality score against a 3.63 opportunity score is the whole story: the problem — a durable structure for domain-oriented Laravel APIs — is worth solving; this artifact does not solve it durably. Do not take a production dependency. Run the one-week spike, absorb the conventions under MIT into an internally owned namespace, and ship an ADR with a named owner and a compatibility test plan. That captures the opportunity value at the package's actual risk level.