About this chapter
The domain holds your business rules; the outside world sends requests. Something has to sit between them, take a request, run one piece of work, and hand back a result. That is the application layer, and this chapter is about writing it well. You'll learn to model each action as a single use case (one class, one method), to separate commands that change state from queries that read it, to move data across boundaries with DTOs instead of leaking Eloquent models, to orchestrate aggregates and repositories without putting rules in the handler, and to treat each use case as one transaction with a single commit at the end. The domain building blocks (aggregates, repositories, domain events) come from Chapter 4; here we put them to work.
Lessons from courses
- 1 The application layer What the application layer is: a thin layer of use cases that orchestrates the domain but holds no business rules, with one handler per action in PHP.
- 2 Commands and queries (CQRS) Command-Query Separation and an intro to CQRS: commands change state and return nothing, queries read and never change state, with separate write and read models.
- 3 DTOs and mapping What Data Transfer Objects are and why they matter: carrying data across boundaries, keeping Eloquent models and arrays out of the domain, with simple PHP mapping.
- 4 Orchestrating the domain How a use case loads aggregates via a repository, calls domain methods and saves - wiring collaborators without holding business rules, with a worked PHP handler.
- 5 Transactions and unit of work Why a use case is the natural transaction boundary: commit once at the end, the Unit of Work pattern, and when to dispatch domain events relative to the commit.
- 6 CQRS in practice CQRS in practice: separate the write model from the read model, with a plain PHP example - and why CQRS does not require event sourcing or two databases.