Trade-offs and non-goals
Pulsar deliberately trades some of stock Laravel's placement freedom for consistency inside app/Pulsar. Choose it when that governance helps the team; keep stock Laravel when the additional structure is more cost than value.
Choose governance for a reason
Pulsar gives audience delivery, business capabilities, and outbound integrations predictable homes. It makes naming and dependency direction explicit, supplies generated starting structures, and gives reviewers shared constraints for feature growth. Those benefits matter most when several developers or several delivery audiences need to evolve one Laravel application without losing a common shape.
The same governance has costs. A team must learn and maintain the vocabulary, accept generated structure, review architecture edges, and surrender some placement freedom. Laravel coupling is deliberate, so moving to another framework would require work and some tests need Laravel integration. Pulsar cannot make those costs disappear; it makes them visible enough to evaluate.
| Pulsar can provide | The team pays for it with |
|---|---|
| Predictable homes for delivery, capabilities, and integrations | More naming decisions and less freedom to place a class wherever convenient |
| Generated starting structures | More files and vocabulary to understand and maintain |
| Explicit dependency constraints | Continuing architecture review rather than relying on generators alone |
| A governed boundary that can grow across audiences | Deliberate Laravel coupling and migration work if the framework changes |
Prefer stock Laravel when it is enough
Stock Laravel is often the better choice when its flexible conventional structure already gives the team enough clarity, especially in a small application or a team that does not want an additional architecture boundary. Pulsar adds predictable homes and review constraints, but it also adds naming decisions, generated structure, architecture review, and less placement freedom.
Choosing stock Laravel is not an architecture failure. Pulsar and ordinary Laravel code may coexist indefinitely, so adoption can remain bounded to the parts of an application where governance earns its cost. Existing Controllers, Requests, Models, routes, providers, configuration, migrations, and tests do not need to move merely because one new slice uses Pulsar.
Assess team readiness in Choose how to adopt Pulsar. For an existing codebase, continue to Adopt Pulsar in an existing application. That guide owns regression and rollback procedures.
Recognize a poor fit
Pulsar is a poor current fit when the team will not enforce the boundary or cannot name a feature as an audience and capability. A broad reorganization instead of a bounded behavior is also a warning. Pulsar is also a poor fit when the application needs operational boundaries that a directory architecture cannot supply.
A generator does not replace architecture review. Generated files can start in the right home and still acquire the wrong responsibilities. The team remains responsible for dependency direction, transaction ownership, and deliberate migration evidence.
Keep the non-goals together
Pulsar does not aim for:
- Framework independence. The Domain is delivery-independent but Laravel-aware; another framework is not assumed to be interchangeable.
- A taxonomy for every Laravel class. Bootstrap, configuration, migrations, tests, and other Laravel-owned seams remain in their conventional locations, and unrelated application code may stay outside
app/Pulsar. - Invisible replacement of Laravel discovery. Providers, routes, bindings, and other registration seams remain explicit and reviewable.
- A runtime layer or library replacement. Pulsar supplies architecture and code generation; Laravel remains the runtime that executes the application.
These are boundaries on Pulsar's claims, not missing features. Treating every class as governed, hiding registration, or presenting Pulsar as another runtime would undermine the Laravel-first architecture it is meant to clarify.
Separate adjacent system decisions
Pulsar's Service vocabulary does not create microservices or independent deployment. Its Domain vocabulary does not promise framework portability. Its Infrastructure vocabulary does not require an Adapter for ordinary Eloquent persistence. Those are separate design decisions with their own costs.
The detailed Architecture pages own placement and dependency rules as they are published. This philosophy section establishes why the boundary exists and when not to choose it; it does not pre-publish every later rule.
Make the decision explicit
Choose Pulsar when predictable placement and review constraints solve a real coordination problem in a Laravel application, and the team accepts Laravel coupling plus the governance cost. Keep stock Laravel when conventional structure is clear enough. Adopt a bounded slice when the answer differs across one codebase, and revisit the decision as the application and team change.