- Is mb-x/architect-bundle a Laravel package?
- No. mb-x/architect-bundle is a Symfony bundle: it ships a Bundle subclass, a DI extension, and YAML/XML service wiring built for Symfony's kernel and container compilation pipeline. Laravel has no bundle concept and no equivalent compiler-pass mechanism, so the package cannot be required into a Laravel app and used as intended. The underlying idea of separating job layers is transferable, but it is a pattern, not a library.
- What problem does mb-x/architect-bundle actually solve?
- It provides an architecture for separating job layers in a Symfony application so controllers, domain logic, and infrastructure do not bleed into one another. The goal is clearer separation of concerns as a codebase grows. In Laravel you reach the same outcome through directory conventions, interfaces, and service-provider bindings rather than a dependency.
- How do I install mb-x/architect-bundle?
- In a Symfony project you would run composer require mb-x/architect-bundle and register the bundle in config/bundles.php. Note that the package is marked deprecated, so even Symfony teams should treat it as reference material rather than a new dependency. For Laravel there is no meaningful install step because nothing in the package targets Laravel.
- Can I use mb-x/architect-bundle in a Laravel app via Composer?
- Composer may resolve it if your PHP constraints happen to overlap, but you would get no usable behaviour: no service provider, no config publishing, and no Laravel container integration. Making it work would mean forking it and writing a Laravel bridge from scratch. That cost exceeds simply writing the layering conventions yourself.
- Does mb-x/architect-bundle support Laravel 10 or Laravel 11?
- No. Laravel 10 and 11 require PHP 8.1+, while Symfony bundles of this vintage typically target Symfony 4/5 and PHP 7.x. Even in a Symfony shop the compatibility envelope is likely narrow. Check the package's composer.json before assuming any version support.
- What PHP and Symfony versions does mb-x/architect-bundle require?
- The repository does not publish a clear support matrix, and bundles from this era usually constrain PHP 7.x with Symfony 4 or 5. That is the opposite of what Laravel 10 and 11 need. Treat the constraints as unknown until you read composer.json, and expect conflicts.
- Is mb-x/architect-bundle still maintained?
- It is explicitly marked deprecated and shows 7 stars with 0 dependents, which means no meaningful external usage, no contributor base, and no downstream pressure to keep it working. There is no observable test suite or documented issue history to mine for failure modes. The bus factor is one.
- Should I fork mb-x/architect-bundle to build a Laravel bridge?
- Not recommended. You would own 100% of the integration surface and 100% of the maintenance for a fork of a deprecated 7-star upstream. The work to port the Symfony wiring into a service provider is more than the work to define layer boundaries directly. If a runtime component is genuinely needed, bind a small first-party service provider you control.
- What are Laravel-native alternatives for layered or DDD architecture?
- Use plain directory conventions, interfaces, and container bindings, optionally with lorisleiva/laravel-actions for use-case classes. Enforce boundaries with Deptrac or PHPStan/Psalm layer rules, which give more durability than any bundle. Starter templates or a make:module Artisan command help teams stay consistent.
- How do I test and enforce a layered architecture in Laravel?
- Unit-test domain and application classes without booting Laravel, and use feature tests for HTTP and infrastructure concerns. Mock ports at the boundary rather than the framework itself. Add Deptrac or PHPStan layer rules to CI so violations fail the build instead of relying on review discipline.