Tour the project you built

The finished feature crosses stock Laravel files and seven generated Pulsar classes inside the existing Client Service. Follow the request inward to the Orders Domain, then trace the shaped response back to the client.

The relevant project tree

The tree includes the installation and Client baseline for orientation. PRD 13 edits none of the application provider, bootstrap builder, backup, Client providers, or provider list. Laravel continues to own the migration and feature test outside app/Pulsar.

Context: completed registered application — Exact relevant tree with only the migration timestamp normalized.

app/
├── Providers/
│   └── PulsarServiceProvider.php
└── Pulsar/
    ├── Domain/
    │   └── Orders/
    │       ├── .gitkeep
    │       ├── Actions/CreateOrder.php
    │       ├── DTOs/CreateOrderData.php
    │       └── Models/Order.php
    └── Services/
        └── Client/
            ├── Modules/
            │   ├── .gitkeep
            │   └── Orders/
            │       ├── Controllers/OrderController.php
            │       ├── Requests/StoreOrderRequest.php
            │       ├── Resources/OrderResource.php
            │       └── UseCases/CreateOrder.php
            ├── Providers/
            │   ├── ClientServiceProvider.php
            │   └── RouteServiceProvider.php
            └── Routes/api.php
bootstrap/
├── app.php
├── app.php.pulsar.bak
└── providers.php
database/migrations/<timestamp>_create_orders_table.php
tests/Feature/PlaceOrderTest.php

What each file owns

The Client Service is the delivery boundary. It points inward to the shared Orders Domain; passive DTO and Model type mentions do not reverse that dependency. Each behavioural call remains explicit.

First-feature file roles and boundaries

Type or file	Owns	Must not own
Routes/api.php	HTTP method, path, name, and Controller target inside the existing Client route group.	Validation, workflow, persistence, or response shaping.
StoreOrderRequest	The HTTP authorization choice and input validation.	Domain mutation, a transaction, or response fields.
OrderController	DTO creation, one UseCase call, top-level status, and Resource assembly.	Direct Action, Query, or Model calls; branching workflow; a transaction.
CreateOrder UseCase	The synchronous workflow and its sole transaction.	HTTP Request, Resource, or response types; another UseCase.
CreateOrder Action	One atomic order insert.	A transaction, Event, another Action or Query, or HTTP concerns.
CreateOrderData	Typed, delivery-neutral input values.	Behavior, framework responses, or persistence.
Order Model	The Eloquent entity and allowed persisted attributes.	HTTP validation, response assembly, or workflow orchestration.
OrderResource	Reusable response fields.	Persistence, a transaction, or the top-level workflow.
Migration	The stock Laravel database schema.	Pulsar architecture behavior.
Feature test	Public HTTP response, validation, and persistence proof.	Production runtime behavior.

The Controller may construct a Domain DTO and accept a returned Domain Model because those are passive type edges. Its one behavioural dependency is the Service UseCase. The UseCase calls one Domain Action, and the Action calls Eloquent. Nothing in the Domain imports the Client Service.

No Infrastructure type appears because this feature has no volatile outbound dependency. Laravel remains present throughout: the Domain uses Eloquent, the UseCase uses the DB facade, and the HTTP edge uses a Form Request and JSON Resource. The Domain is independent of delivery, not Laravel.

Follow the HTTP Request

Place an order through the HTTP workflow. The Client Service handles HTTP delivery while the Orders Domain owns typed data and the atomic persistence action.

Interpretation. The Controller has one workflow dependency. Only the UseCase brackets the Action with a transaction, while the Resource shapes the returned Order after the workflow completes.

Laravel receives POST /api/client/orders through the route group registered by the Client Service. StoreOrderRequest authorizes this tutorial Request and returns validated data. Laravel then calls OrderController::store(), which turns those values into CreateOrderData and invokes the UseCase once.

The UseCase begins the transaction before it calls the Action. The Action asks the Order Model to insert the two attributes; Eloquent returns the persisted Model. The UseCase commits only after that Action returns, then gives the Model back to the Controller.

Finally, OrderResource selects id, customer_name, and total_cents. The Controller assigns 201 Created, and Laravel returns the Resource envelope as JSON. Response shaping therefore stays on the delivery side of the completed Domain mutation.

Laravel and Pulsar keep separate boundaries

Pulsar generated the Domain, DTO, Model, Action, UseCase, Request, Controller, and Resource starting structures. The route file also began with the generated Client Service, but the order route is handwritten application code. Laravel generated and continues to own the migration and feature-test file.

This coexistence is intentional. app/Pulsar follows Pulsar's placement and dependency rules, while bootstrap, routes, migrations, tests, configuration, factories, and other stock Laravel concerns may keep their conventional homes. The architecture landing is the currently published entry to that broader boundary.

What this example leaves out

The first feature proves one synchronous database write. It intentionally omits authentication, policies, tenancy, events, listeners, queues, Jobs, Commands, Operations, Queries, Contracts, external Adapters, cross-Domain calls, additional Services, factories, seeders, and deployment. Those concerns require their own workflows; adding them here would hide the dependency path this example is meant to teach.

Return to Build your first Pulsar feature for the executable steps, or review How Pulsar bootstraps Laravel for the provider and route-loading chain.