Think Multi App Laravel Package

Product Decisions This Supports

• Architecture: monolith vs. multi-app vs. microservices. This package is the "modular monolith" middle option for ThinkPHP 6 — one repository, one deployable, one database, but each surface (admin, api, web, partner) gets its own app directory, namespace, config, routes, middleware, and views. It makes "carve out a separate surface" a routing decision rather than a platform rewrite.
• Build vs. buy. Adopting it replaces hand-rolled subdomain-to-namespace dispatch (typically entry-point index.php glue plus custom routing). The alternative buys are nginx-level splitting into separate codebases, or nwidart/laravel-modules-style module boundaries — which only apply if you're not on ThinkPHP.
• URL and entry-point strategy. It makes path-prefix (example.com/admin) vs. subdomain (admin.example.com) a first-class product decision, which in turn drives cookie scoping, SEO, and CDN/cache configuration.
• Feature packaging and release cadence. Whether the admin console and the public API ship as one product with one release train, or as distinct deliverables that merely share a repo. Multi-app gives you the separation of concerns without the separation of pipelines — a deliberate trade you should make explicitly.
• Roadmap sequencing. A cheap way to stand up a v2 API or a partner portal alongside the existing product without a platform migration, and reversible later by promoting an app to its own service.
• Stack standardization. A prerequisite decision (ThinkPHP 6 as house framework) sits upstream of this package; the package itself is not a reason to pick the stack.

When to Consider This Package

Consider it when:

• You are already on ThinkPHP 6 and have, or expect, two or more distinct surfaces with different audiences (backoffice, public API, mobile/H5, partner portal).
• You want per-app isolation of config, middleware, routes, and views without splitting repositories or introducing service-to-service communication.
• Your team is small enough that a single deployable and a single database is an asset, not a constraint.
• You need domain- or subdomain-based dispatch with minimal boilerplate.
• You inherited a ThinkPHP 5 multi-module application and want a maintained, first-party path forward.
• Licensing matters: Apache-2.0, published under the official top-think organization — acceptable for commercial use and redistribution.

Look elsewhere when:

• You are on Laravel, Symfony, or anything that is not ThinkPHP 6. The framing of this as a "Laravel/PHP package" is a mismatch — it provides nothing to a Laravel codebase. Laravel's equivalents are per-concern (route service providers, domain-routing middleware) or a module package.
• You need independent deploys, independent scaling, or per-app team ownership. Folders and namespaces do not give you those; real services do.
• You need strict data isolation or multi-tenancy enforced at the database layer.
• You need a deep hiring pool or English-language documentation and third-party supply. ThinkPHP's ecosystem, docs, and community are concentrated in Chinese-language resources.
• You need independent adoption signals. 20 stars and 0 listed dependents is very thin external validation. The credibility here comes from the maintainer organization, not from community vetting — treat it as a supported internal component, not a battle-tested third-party bet.

How to Pitch It (Stakeholders)

For executives: This is a small, free, Apache-2.0 extension maintained by the official ThinkPHP 6 team that lets a single codebase serve several products — admin console, public API, partner portal — as cleanly partitioned applications. It is the inexpensive option that defers the expensive decision of splitting into separate services, and it is reversible: any app can later be promoted to its own deployment. Two caveats to state plainly. First, it is ThinkPHP-specific; if we standardize on Laravel it is irrelevant. Second, with roughly 20 stars it carries little external validation — our confidence rests on the maintainer organization, not the community. Net: low cost, low lock-in, but not a substitute for due diligence on the framework choice itself.

For engineering: Multi-app dispatch for ThinkPHP 6 — resolves an app namespace from domain or path prefix and keeps configs, routes, middleware, and views isolated per app, on a standard single deploy. Integration cost is near zero: one Composer dependency plus a directory convention and entry-point configuration. Architecturally it is the modular-monolith middle ground — you get real boundaries without distributed-systems overhead, and each app is a clean extraction candidate later. The principal risk is ecosystem concentration (Chinese-language docs, thinner third-party supply), not code risk; the dependency surface is small and the license is permissive.