Why Pulsar is Laravel-first
Pulsar's Domain is independent of delivery, not independent of Laravel. It may use Eloquent, Laravel events, authorization, and the container because Pulsar optimizes for a clear Laravel application structure rather than portability to another framework.
Optimize for the application you are building
Pulsar is an opinionated Laravel architecture. It gives a team predictable homes for audience delivery, shared business capabilities, and outbound integrations inside one application. That shared vocabulary makes placement and dependency choices reviewable instead of leaving every feature to invent its own structure.
Laravel is therefore a design input, not an implementation detail to conceal. A Domain Model can be an Eloquent Model. A Domain Event can use Laravel's contracts for Events. A Policy can use Laravel authorization, and application wiring can use the container. The later architecture pages specify the rules for those types; this page owns the reason they are allowed.
The boundary is still meaningful. HTTP Requests, Resources, console input, and queue delivery belong at delivery edges. Domain capabilities do not depend on a Client Controller or an Admin Request. Sharing a Laravel runtime does not permit delivery concerns to point back into a Domain.
Do not require a framework-independent Domain
Framework portability is not a Pulsar goal. Requiring every Domain value and persistence step to pass through a framework-neutral twin would introduce another representation and translation layer solely to preserve a hypothetical framework switch. Pulsar instead lets Laravel applications express their capabilities directly with Laravel tools.
That choice is deliberate coupling. Moving a Pulsar Domain to another framework would require work, and tests that exercise Eloquent, events, authorization, or container behavior may need Laravel integration. Pulsar does not claim that this always produces less code or better tests. It claims that the coupling is visible, governed, and appropriate for teams intentionally building a Laravel application.
The practical question is not “could this class run without Laravel?” It is “does this capability remain independent of how a consumer reaches it?” An Orders capability can serve HTTP, console, or queue delivery while still using Eloquent. Delivery independence preserves reuse inside the application without pretending Laravel is optional.
Keep architecture distinct from runtime
Pulsar supplies architecture guidance and code generators. Laravel remains the runtime that boots the application, resolves container dependencies, handles requests, dispatches events, and runs both ordinary Laravel code and governed code under app/Pulsar. Pulsar is not a second application runtime or a replacement framework.
Generated structure is a starting point, not hidden machinery. Teams own the generated application code and review its placement and dependencies like any other code. Laravel's normal discovery and registration seams remain visible where the framework owns them.
Understand the influences without treating them as specifications
Pulsar does not claim conformance to Clean Architecture; it is influenced by Lucid, Clean Architecture, and Domain-Driven Design. Those traditions help explain its emphasis on explicit capabilities, dependency direction, and boundary names. They are historical influences, not conformance standards: Pulsar's own documented rules decide whether an application follows Pulsar.
In particular, “Domain” here does not mean a framework-pure core, and “Service” does not mean a separately deployed system. Pulsar adopts useful ideas in a Laravel-first form rather than claiming a complete implementation of another architecture.
Read the Orders example at the right scale
The documented Orders feature is a small synchronous slice with a traceable boundary: Client delivery invokes an Orders capability, which persists an Eloquent Model. It teaches the path through the architecture; it is not proof that Pulsar fits every application, team, or approach to orders.
Build that slice in Build your first Pulsar feature, or inspect the completed files in Tour the project you built. Then continue to the app/Pulsar architecture boundary to decide which types are governed.