Services model audiences
A Service groups delivery for a consumer audience such as Client, Admin, or Internal inside one Laravel application. A Domain models a shared business capability, a Module groups related delivery and workflow behavior within a Service, and Infrastructure holds concrete outbound Adapters.
Use each boundary for one question
| Term | Question it answers | Example |
|---|---|---|
| Service | Which audience receives this delivery? | Client, Admin, or Internal |
| Module | Which related delivery and workflow slice serves that audience? | Services/Client/Modules/Orders |
| Domain | Which Laravel-aware business capability can be shared? | Domain/Orders |
| Infrastructure | Which concrete outbound Adapter talks to another system? | An Adapter that implements a Domain-owned Contract |
These boundaries are intentionally asymmetric. Services organize consumer-facing delivery. Domains organize capabilities that may be shared across audiences. Infrastructure contains concrete integration details that point back to Domain-owned Contracts.
Let Services vary delivery by audience
A Client and an Admin may act on the same Orders Domain through different delivery rules. Their Controllers, Requests, Resources, commands, or Jobs can differ because each audience has different inputs, authorization context, response shapes, and workflows. Those delivery types live in the appropriate Service Module.
The Service name should describe the consumer audience, not a business capability or technical transport. Client and Admin are useful audience names. OrdersService, HttpService, or DatabaseService confuse the boundary with a Domain, transport, or implementation mechanism.
A Module keeps related delivery and workflow behavior together within its Service. Services/Client/Modules/Orders can contain the Client-facing Orders entry point and UseCase. The shared Eloquent Model, Action, DTO, and other business capability types belong in Domain/Orders rather than being duplicated for every audience.
Separate Pulsar Services from microservices
In Pulsar, a Service is not a microservice. It does not imply an independent deployment, process, database, schema, network boundary, or team-owned system. It is an audience delivery boundary inside one Laravel application and one runtime.
Teams that require independent deployment or those other operational boundaries need a separate system design. Pulsar neither recommends nor forbids microservices outside the monolith; it does not use “Service” to promise them.
This distinction prevents directory names from making architectural claims the application cannot satisfy. A Client Service and Admin Service can share the same Domain objects and database transaction because they are delivery views inside the same application.
Share capabilities through Domains
A Domain names a business capability such as Orders, Billing, or Identity. It is Laravel-aware: it may use Eloquent and other Laravel facilities while remaining independent of Client, Admin, HTTP, CLI, or queue delivery.
Delivery points inward to the capability. If both Client and Admin work with Orders, they may use Domain/Orders rather than copying business behavior into two Services. The detailed dependency matrix will define which edges are allowed; the stable principle is that delivery does not become the owner of shared business capability.
Add Infrastructure only for a real outbound edge
Infrastructure holds concrete outbound Adapters. It is not a generic home for all framework code, persistence, or utilities. A Domain owns the Contract that expresses what it needs; the Infrastructure Adapter implements that Contract for a concrete external system.
For example, Billing could own a PaymentGateway Contract while a Payments Infrastructure area contains the concrete Adapter. That sentence establishes the vocabulary only; binding and integration tutorials belong to later pages.
The first Orders slice has no Infrastructure type because it has no volatile outbound dependency. Adding an empty Infrastructure layer would not improve the example.
Keep the example in proportion
The Orders walkthrough uses one Client Module and one Orders Domain to teach a small synchronous boundary. It is not evidence that Pulsar fits every application, team, or approach to orders, and it does not represent every audience or integration.
Build the slice in Build your first Pulsar feature, inspect its files in Tour the project you built, or return to the app/Pulsar architecture boundary for placement classification.