Architect Bundle Laravel Package

Technical Evaluation

Architecture fit — the central finding is a framework mismatch. mb-x/architect-bundle is a Symfony bundle, not a Laravel package. It ships a Bundle subclass, DI extension, and YAML/XML service wiring designed for Symfony's kernel and container compilation pipeline. Laravel has no bundle concept and no equivalent compiler-pass mechanism; its composition root is ServiceProvider + config/*.php + container bindings. Nothing in this package can be composer required into a Laravel app and used as intended.

What is transferable is the underlying idea: separating job layers (typically Domain / Application / Infrastructure, with command-handler or use-case boundaries) so business logic does not leak into controllers, Eloquent models, or framework glue. That is a pattern, not a library. Laravel teams implement it with directory conventions, interfaces, and container bindings — none of which require this dependency.

Integration feasibility — low, and not worth the adapter cost. Making this usable would mean forking it and writing a Laravel bridge: a service provider, config publishing, and reimplementing any container wiring the bundle does via Symfony extensions. That is net-new code written against a 7-star upstream with zero dependents, meaning we would own 100% of the integration surface and 100% of the maintenance. The work required to port it exceeds the work required to simply write the layering conventions ourselves.

Technical risk — high on every axis except conceptual.

• Bus factor of one. 7 stars and 0 dependents indicate no meaningful external usage, no contributor base, and no downstream pressure to keep it working.
• Version drift. Symfony bundles of this vintage typically target Symfony 4/5 and PHP 7.x; Laravel 10/11 require PHP 8.1+. Even in a Symfony shop the compatibility envelope is likely narrow.
• No validation signal. The 0.095 composite score and absence of dependents mean no production evidence, no issue tracker history to mine for failure modes, and no security disclosure path.
• No observable documentation or test suite. Onboarding would be source-reading.

Key questions to resolve before any decision:

1. What specific problem are we solving — coupling in controllers, untestable business logic, or inconsistent structure across teams? If the answer is "we want clearer layers," a package is the wrong instrument.
2. Is there a Laravel-native alternative already covering this (e.g., established DDD/layered skeletons, lorisleiva/laravel-actions, or plain internal conventions)?
3. What are the package's composer.json constraints — PHP version, Symfony version, license? A restrictive or orphaned license kills the fork path.
4. Does the maintainer respond to issues, and is there a tagged release history?
5. Would adopting this create a permanent fork obligation, and who owns it?

Integration Approach

Stack fit. Poor at the artifact level, adequate at the concept level. Laravel's idioms — service providers, facades, Eloquent as active record, form requests, jobs and events — already encode a layer story, and the friction teams feel is usually about discipline, not missing infrastructure. The bundle's layering model maps onto Laravel directories and interfaces cleanly; its code does not map onto Laravel's container at all.

Migration path. Recommended path: do not add the dependency. Harvest the architecture as an internal standard:

• Write an ADR defining the layer boundaries and the allowed dependency directions (e.g., Domain must not import Illuminate; Application orchestrates; Infrastructure implements ports).
• Scaffold the directory structure in a starter template or a make:module artisan command.
• Enforce with static analysis (PHPStan/Psalm layers, or Deptrac), which is where the real durability comes from — far more than any bundle.
• If a runtime component is genuinely needed (handler dispatch, command bus), bind it in a small first-party service provider we control.

If leadership insists on evaluating the upstream code, fork-then-port is the only viable sequence — and it should be scoped as a spike with an explicit kill criterion, not a committed migration.

Compatibility. Assume incompatibility until proven. Verify PHP constraint, Symfony constraint, autoload PSR-4 mapping, and whether the bundle uses deprecated container APIs. Even a successful port leaves us tracking an unmaintained upstream, so the fork would immediately become a standalone first-party package with the original as a one-time reference.

Sequencing.

1. Confirm the problem statement and success metric (e.g., "new modules ship with zero framework imports in Domain," "controller LOC down X%").
2. Pilot the layering convention in one bounded context using hand-written structure — no dependency.
3. Codify into the starter template plus automated layer-boundary checks in CI.
4. Measure against the success metric at one quarter.
5. Only if a reusable runtime component emerges from the pilot do we consider packaging it — as first-party code with an owner.

Operational Impact

Maintenance. Ownership transfers entirely to us on day one. There is no upstream release cadence to ride, no dependency-bot signal that matters (a fork doesn't get patched), and no community triage. Any breakage from a PHP or framework upgrade is our incident. The true cost is not the install — it is the indefinite fork obligation, which is difficult to sunset once modules depend on it.

Support. No documentation, no community footprint, no Stack Overflow corpus. Support means reading the source and asking whoever wrote the port. Compare against internal conventions, where the team that wrote the ADR is the support channel and can answer in minutes.

Scaling. The package itself doesn't scale (it's a small bundle; scale is not the concern). The architectural benefit — testability, swappable infrastructure, parallel team ownership of modules — is real and worth pursuing. The critical point is that this benefit is fully achievable without the dependency and is largely delivered by CI-enforced boundary rules rather than by any library. Adopting a package to obtain a convention confuses the artifact with the practice.

Failure modes.

• Silent abandonment: the dependency appears healthy in composer.json but receives no fixes; a future PHP minor breaks it mid-sprint.
• Fork rot: our port diverges from upstream, making later re-sync impossible and turning a "temporary" fork into permanent legacy.
• Framework-idiom collision: engineers versed in Laravel fight Symfony-style wiring; double cognitive load with no upstream payoff.
• Convention drift: the package enforces structure at the container level, but new code bypasses it; without Deptrac/PHPStan gates the layering erodes anyway, package or not.
• Security blind spot: unmaintained code is not covered by advisory tooling the way a mainstream dependency is, so vulnerabilities surface late or not at all.

Ramp-up. Highest of the options considered. Engineers would need to learn Symfony bundle conventions (irrelevant to the rest of the stack), the port's specifics, and the intended layering — three things instead of one. A hand-rolled convention requires learning only the layering, which is the actual objective.

Recommendation. Decline as a dependency. The composite score (0.095) and zero dependents are consistent with what the code inspection shows: a framework-specific artifact with no adoption. Treat the repository as a reference implementation for an internal layering standard, enforce that standard with static analysis in CI, and revisit packaging only if a genuinely reusable, first-party runtime component emerges from the pilot. Budget the effort saved on integration against the ADR, starter template, and boundary checks — which is where the durable value sits.