Best Books to Learn Laravel, in Reading Order
This curriculum starts by grounding you in modern PHP before moving into Laravel's core framework, then advances into architecture, testing, and design patterns that make Laravel applications production-ready. Each stage builds directly on the last: you need solid PHP before Laravel makes sense, and you need Laravel fluency before the architectural books pay off.
Modern PHP Foundations
BeginnerUnderstand modern PHP syntax, type systems, OOP principles, Composer, and the PHP ecosystem well enough that Laravel's conventions feel natural rather than magical.
▸ Study plan for this stage
Pace: 8–10 weeks total: Weeks 1–6 on "PHP 8 Objects, Patterns, and Practice" (~25–30 pages/day, focusing on Parts 1–3); Weeks 7–10 on "Modern PHP" (~20–25 pages/day, a lighter read designed to be absorbed deliberately with hands-on experimentation alongside each chapter).
- PHP 8 type system: scalar type declarations, union types, nullables, return types, and the match expression — as covered in Zandstra's opening chapters
- Object-Oriented Programming pillars in PHP 8: classes, interfaces, abstract classes, traits, visibility, and late static binding (Zandstra Part 1)
- Core Gang-of-Four and enterprise patterns — Factory, Singleton, Observer, Strategy, Decorator, and MVC — and why Laravel's architecture mirrors them (Zandstra Part 2)
- Namespaces and autoloading: how PSR-4 autoloading works and why it is the backbone of every modern PHP project (Zandstra + Lockhart Ch. 2)
- Composer as a dependency manager: semantic versioning, composer.json/composer.lock, autoload configuration, and the Packagist ecosystem (Lockhart Ch. 3)
- Modern PHP features from Lockhart: generators, closures and anonymous functions, built-in HTTP servers, and the PHP-FIG standards (PSR-1, PSR-2, PSR-7, PSR-12)
- Error handling and exceptions: exception hierarchies, custom exceptions, and the SPL exception classes (Zandstra Part 1 + Lockhart)
- PHP ecosystem hygiene: environment variables with phpdotenv, security best practices (password hashing, filtering input, escaping output), and testing fundamentals with PHPUnit (Lockhart + Zandstra Part 3)
- After reading Zandstra, can you explain the difference between an interface and an abstract class, and give a concrete example of when you would choose each in a Laravel-style service layer?
- How does PSR-4 autoloading (described in both books) connect to the 'autoload' key in composer.json, and what would break in a Laravel app if it were misconfigured?
- Zandstra dedicates significant space to the Factory and Strategy patterns — how do these map to Laravel's service container bindings and driver-based systems (e.g., Mail, Cache)?
- Lockhart introduces closures and anonymous functions as first-class citizens in modern PHP — how does this underpin Laravel's routing syntax and collection methods?
- What is the purpose of composer.lock, and why should it be committed to version control on an application (as opposed to a library)?
- From Lockhart's security chapter, what are the three non-negotiable practices for handling user-supplied data, and how does Laravel's ORM and Blade templating automate some of them?
- **OOP Modeling Exercise (Zandstra Part 1):** Build a small CLI inventory system (products, categories, discounts) using only PHP 8 classes, interfaces, and traits — no frameworks. Enforce strict types at the top of every file and use constructor property promotion throughout.
- **Pattern Implementation (Zandstra Part 2):** Implement the Observer pattern from scratch, then refactor it to use PHP's built-in SplObserver/SplSubject interfaces. Write a short comparison of your implementation vs. Laravel's Event/Listener system.
- **Composer Package Exploration (Lockhart Ch. 3):** Create a fresh composer.json from scratch (no `composer create-project`), require at least three Packagist packages (e.g., vlucas/phpdotenv, ramsey/uuid, guzzlehttp/guzzle), configure PSR-4 autoloading for your own namespace, and verify it with a small script.
- **Closures & Generators Lab (Lockhart):** Write a generator that lazily reads a large CSV file line by line, then pipe the results through a chain of closures (filter, transform, reduce) — mirroring how Laravel's lazy collections work under the hood.
- **PHPUnit Test Suite (Zandstra Part 3 + Lockhart):** Write a PHPUnit test suite for the inventory system from Exercise 1. Include at least one data provider, one mock object replacing a database dependency, and one test that asserts a custom exception is thrown.
- **Code Standards Audit:** Take the inventory system codebase and run PHP_CodeSniffer against the PSR-12 standard, then PHP Stan at level 5. Fix every reported issue and document what each category of error taught you about professional PHP conventions.
Next up: Completing this stage means you can read Laravel's source code — its service container, facades, and Eloquent models — and recognize the PHP 8 OOP constructs, Composer wiring, and design patterns underneath them, so the next stage (diving into Laravel itself) feels like applying familiar tools rather than learning an alien framework.
The definitive traditionally-published guide to PHP OOP, covering classes, interfaces, traits, and design patterns in PHP — all concepts Laravel uses heavily. Read this first to build the object-oriented vocabulary the rest of the curriculum assumes.
A concise O'Reilly title that covers namespaces, Composer, PSR standards, and modern PHP best practices — exactly the ecosystem layer that sits beneath Laravel. Read it second to bridge raw OOP knowledge to real-world PHP project structure.
Laravel Core — The Framework Inside and Out
BeginnerGain confident, practical mastery of Laravel's routing, Eloquent ORM, Blade templating, middleware, queues, authentication, and the service container.
▸ Study plan for this stage
Pace: 10–12 weeks total. Weeks 1–8: "Laravel" by Matt Stauffer (~40–50 pages/day, 5 days/week), reading chapters in order and pausing to code along with each feature. Weeks 9–12: "PHP and MySQL Web Development" by Luke Welling (~35–45 pages/day, 5 days/week), focusing on the PHP fundamentals and MySQL cha
- Laravel's request lifecycle and the service container — how bindings, singletons, and dependency injection wire the entire framework together (Stauffer, Ch. 1–3)
- Routing and controllers — defining RESTful routes, route model binding, named routes, and resource controllers (Stauffer, Ch. 3–4)
- Blade templating engine — layouts, components, directives (@foreach, @if, @yield, @section), and passing data to views (Stauffer, Ch. 4)
- Eloquent ORM — models, migrations, relationships (hasOne, hasMany, belongsToMany, polymorphic), query scopes, and accessors/mutators (Stauffer, Ch. 5–6)
- Middleware — creating, registering, and applying HTTP middleware for authentication guards, logging, and request transformation (Stauffer, Ch. 10)
- Authentication and authorization — Laravel Breeze/Jetstream scaffolding, Gates, Policies, and role-based access control (Stauffer, Ch. 9)
- Queues and jobs — dispatching jobs, configuring queue drivers, handling failures, and understanding async processing (Stauffer, Ch. 16)
- Raw PHP & MySQL foundations — how PDO, prepared statements, and relational database design work beneath Eloquent's abstraction (Welling, Parts 2–3)
- How does Laravel's service container resolve dependencies automatically, and how would you manually bind an interface to a concrete implementation in a service provider?
- What is the difference between route model binding and a standard route parameter, and when would you choose one over the other?
- Walk through the Eloquent relationship chain for a blog with Users, Posts, Tags, and Comments — which relationship type does each pair use and why?
- How does middleware differ from a controller constructor for protecting routes, and what is the correct order of middleware execution in the Laravel pipeline?
- What happens step-by-step when a queued job is dispatched — from the dispatch() call through the queue driver to the worker process — and how do you handle a failed job?
- Using knowledge from Welling's MySQL chapters, explain what Eloquent's query builder generates as raw SQL for a whereHas() call, and why understanding that matters for performance.
- Route & Controller drill (Stauffer Ch. 3–4): Build a fully RESTful resource for a 'Project' entity — hand-write every route, generate a resource controller, and verify all seven CRUD endpoints with a tool like Postman or curl.
- Blade layout system (Stauffer Ch. 4): Create a master layout with a nav, sidebar, and footer using @yield/@section, then build three child views that extend it; add a Blade component for a reusable alert card.
- Eloquent relationships lab (Stauffer Ch. 5–6): Scaffold a mini blog with Users, Posts, Categories, Tags (many-to-many), and Comments; seed 50+ rows with factories and write at least five queries using with() eager loading — then inspect the query log to confirm N+1 is eliminated.
- Middleware challenge (Stauffer Ch. 10): Write a custom middleware that checks for a request header API-Version and rejects requests below a minimum version with a 400 response; register it as a route middleware and apply it selectively.
- Queue & job pipeline (Stauffer Ch. 16): Create a SendWelcomeEmail job, dispatch it on user registration, run a queue worker, simulate a failure by throwing an exception, and configure the failed_jobs table to capture it.
- Raw SQL to Eloquent mapping (Welling Parts 2–3 → Stauffer): Take three non-trivial raw MySQL queries from Welling's exercises (e.g., a JOIN with aggregation), rewrite them first with Laravel's query builder and then with Eloquent scopes, and compare the output SQL using DB::listen().
Next up: Completing this stage gives you a working mental model of how Laravel's layers — HTTP, database, auth, and async — interact, which is the essential foundation for tackling advanced topics such as API design, testing strategies, performance optimization, and package development in the next stage.
The canonical, traditionally-published O'Reilly book on Laravel — comprehensive, version-current, and written by one of the framework's most respected voices. Work through it cover-to-cover; it is the backbone of this entire curriculum.
A long-standing Addison-Wesley reference that deepens your understanding of the database and server layer underneath Laravel, reinforcing why Eloquent and query-builder choices matter. Read it alongside or just after Stauffer to solidify the persistence layer.
Testing Laravel Applications
IntermediateWrite feature tests, unit tests, and browser tests for Laravel apps using PHPUnit and Laravel's built-in testing helpers, and adopt a test-driven workflow.
▸ Study plan for this stage
Pace: 8–10 weeks total. Weeks 1–4: "The Art of Unit Testing" by Roy Osherove (~25–30 pages/day, reading all 3 parts sequentially). Weeks 5–10: "Test-Driven Development with PHP 8" by Rainier Sarabia (~20–25 pages/day, pairing every chapter with hands-on Laravel coding).
- What makes a good unit test: trustworthy, maintainable, and readable (Osherove's three pillars)
- Isolating units under test using stubs, mocks, and fakes — and knowing when to use each (Osherove, Part 2)
- Interaction testing vs. state-based testing and avoiding over-specification of mocks (Osherove)
- Test hierarchy in Laravel: unit tests vs. feature tests vs. browser/end-to-end tests, and how PHPUnit underpins them all (Sarabia)
- Test-Driven Development red-green-refactor cycle applied to PHP 8 and Laravel controllers, services, and models (Sarabia)
- Laravel-specific testing helpers: RefreshDatabase, actingAs(), assertJson(), withHeaders(), and HTTP test methods (Sarabia)
- Testing Laravel-specific concerns: Eloquent models, queued jobs, events, notifications, and mail fakes (Sarabia)
- Organizing a sustainable test suite: naming conventions, test doubles strategy, and avoiding brittle tests (both books)
- According to Osherove, what are the three properties of a good unit test, and how do you evaluate a test you've written against each one?
- What is the difference between a stub and a mock in Osherove's terminology, and when should you choose one over the other in a Laravel service class test?
- How does the red-green-refactor cycle described by Sarabia change the order in which you write Laravel feature code versus test code, and why does that matter?
- Which Laravel testing helpers (e.g., RefreshDatabase, Mail::fake(), Event::fake()) does Sarabia use to isolate infrastructure concerns, and what problem does each solve?
- How would you test a Laravel controller endpoint that fires an event and sends a notification, without actually hitting the database or mail server?
- What signs in a test suite — as identified across both books — indicate that tests are becoming brittle or tightly coupled to implementation details?
- Osherove drill — Refactor a legacy PHP class (no Laravel): write three tests for it that satisfy all three of Osherove's pillars (trustworthy, maintainable, readable), then introduce a stub to remove an external dependency.
- Mock vs. stub comparison: pick a Laravel service class that calls an external API; write one test using a stub (verify returned value) and one using a mock (verify the call was made), then document in comments why each approach was chosen.
- TDD feature build (Sarabia workflow): using strict red-green-refactor, build a small Laravel CRUD resource (e.g., a Task API) — write every feature test before writing a single line of production code, committing after each green phase.
- Laravel fakes exercise: write feature tests for a user-registration flow that sends a welcome email and fires a Registered event; use Mail::fake() and Event::fake() to assert both side-effects without real infrastructure.
- Database isolation practice: convert a test suite that uses raw database seeding to use RefreshDatabase and model factories exclusively; measure and compare test run times before and after.
- Browser/end-to-end stretch goal: using Laravel Dusk (referenced in Sarabia's broader TDD context), write two browser tests for a login form — one happy path and one validation-error path — and integrate them into the same PHPUnit suite.
Next up: Mastering isolated unit and feature testing here builds the discipline and safety net needed to confidently tackle more advanced Laravel architecture topics — such as domain-driven design, complex service layers, or API design — because a robust test suite makes large-scale refactoring and new patterns safe to explore.
A traditionally-published Manning classic that teaches unit-testing principles — mocks, stubs, test doubles, and test design — in a language-agnostic way that maps cleanly onto PHPUnit and Laravel's testing layer. Read it first to internalize the 'why' before the Laravel-specific 'how'.
A Packt title focused specifically on applying TDD in modern PHP projects, bridging the general principles from Osherove into the PHP and Laravel context with practical examples.
Architecture, Design Patterns & Clean Code
IntermediateApply SOLID principles, domain-driven design concepts, and classic design patterns to structure large Laravel codebases that are maintainable and extensible.
▸ Study plan for this stage
Pace: 14–16 weeks total, ~25–35 pages/day. Week 1–4: "Clean Code" (~464 pages, ~20 pages/day with reflection time); Week 5–9: "Design Patterns" (~395 pages, ~25 pages/day, revisiting each pattern in a Laravel context); Week 10–16: "Patterns of Enterprise Application Architecture" (~560 pages, ~30 pages/da
- Clean Code principles: meaningful naming, small focused functions, the Single Responsibility Principle at the code level, and the Boy Scout Rule as applied to Laravel controllers, services, and models
- SOLID principles as a unifying thread across all three books — especially how Open/Closed and Dependency Inversion manifest in Laravel's service container and interface bindings
- GoF Creational patterns (Factory Method, Abstract Factory, Singleton, Builder) and their direct counterparts in Laravel: service providers, the App::bind/singleton API, and fluent query builder
- GoF Structural patterns (Decorator, Facade, Proxy, Adapter) and how Laravel's own Facade system, middleware pipeline, and cache/storage drivers embody these patterns
- GoF Behavioral patterns (Strategy, Observer, Command, Template Method, Chain of Responsibility) mapped to Laravel Events/Listeners, Jobs, Pipelines, and Form Requests
- Fowler's layering patterns — Transaction Script, Table Module, Domain Model — and when to graduate a Laravel app from Eloquent-heavy Active Record toward a richer domain model
- Fowler's data-source architectural patterns: Active Record vs. Data Mapper, and how Eloquent blends both, plus the Repository pattern as a seam for testability
- Fowler's web presentation and service-layer patterns: Front Controller, Page Controller, Service Layer, and Unit of Work, and how they map to Laravel's routing, controllers, and database transactions
- After reading Clean Code, how would you refactor a 200-line Laravel controller method into smaller, well-named units while preserving readability and testability?
- From Design Patterns, which GoF patterns does Laravel's core already implement (e.g., Facade, Observer, Command), and how does knowing the canonical pattern help you extend or override that behavior correctly?
- How does the Strategy pattern (GoF) relate to Laravel's use of driver-based services (mail, cache, queue), and how would you add a custom driver without modifying existing code (Open/Closed Principle)?
- From Patterns of Enterprise Application Architecture, when should you move beyond Eloquent's Active Record approach toward a Data Mapper + Repository pattern, and what are the concrete trade-offs in a Laravel project?
- How does Fowler's Service Layer pattern complement Laravel's Action or Service class conventions, and what responsibilities should never leak into it?
- How do the Unit of Work and Identity Map patterns described by Fowler manifest inside Eloquent, and what problems do they solve that you might otherwise handle manually?
- Clean Code exercise — Controller Audit: Pick any existing Laravel controller in a personal or open-source project. Apply Martin's naming, function-size, and SRP rules. Extract service classes, rename methods to reveal intent, and eliminate all comments that merely restate the code. Commit before/after and write a short diff-review note.
- Design Patterns exercise — Pattern Catalogue in Laravel: Create a markdown file mapping all 23 GoF patterns to either (a) a Laravel core class that implements it, (b) a place in your own app where you will introduce it, or (c) a note that it is not applicable. Implement at least three patterns (e.g., Decorator for logging a cache layer, Command for a dispatchable Job, Strategy for a swappable paym
- Design Patterns exercise — Custom Facade: Build a Laravel package skeleton that exposes a non-trivial service (e.g., a currency converter) through a proper Facade, a service provider, and an interface, demonstrating Dependency Inversion and the Facade structural pattern simultaneously.
- PEAA exercise — Repository Layer: Take a feature that uses Eloquent directly in controllers and introduce a Repository interface + Eloquent implementation. Bind the interface in a service provider, then write a second in-memory implementation used exclusively in unit tests — proving the seam works.
- PEAA exercise — Domain Model Spike: Identify one bounded concept in your app (e.g., Order, Subscription) that has grown beyond simple CRUD. Extract a plain PHP domain object with its own business rules, a Data Mapper to persist it, and a Service Layer method that orchestrates the use case — keeping Eloquent out of the domain class entirely.
- Cross-book capstone — Architecture Decision Record (ADR): Write a one-page ADR for a real or hypothetical Laravel feature, citing specific guidance from Clean Code (naming/SRP), at least two GoF patterns, and at least one PEAA pattern. Justify every structural choice and note what you would change if the app scaled 10×.
Next up: Mastering these timeless structural principles and patterns gives you the vocabulary and the instincts to evaluate Laravel-specific advanced topics — such as Domain-Driven Design bounded contexts, CQRS, event sourcing, and microservice decomposition — which form the natural next stage of the curriculum.
The foundational Prentice Hall text on writing readable, maintainable code — its principles apply directly to Laravel service classes, controllers, and repositories. Read it first in this stage to establish the quality bar.
The original 'Gang of Four' book; Laravel's service container, facades, and event system are direct implementations of patterns described here. Reading it at this stage lets you see the framework's internals with new clarity.
Fowler's Addison-Wesley catalog of enterprise patterns — Active Record, Repository, Unit of Work, and more — maps directly onto Eloquent and Laravel's architecture. It is the theoretical backbone behind every architectural decision in a serious Laravel app.
Advanced PHP & Domain-Driven Design
ExpertDesign complex, domain-rich Laravel applications using DDD tactical patterns, hexagonal architecture, and advanced PHP type-system features.
▸ Study plan for this stage
Pace: 8–10 weeks, ~25–30 pages/day (the "Blue Book" is ~560 pages of dense material; budget extra time for re-reading tactical pattern chapters and mapping concepts to Laravel code)
- Ubiquitous Language — building a shared, precise vocabulary between developers and domain experts that permeates every layer of a Laravel codebase
- Bounded Contexts — partitioning a large Laravel application into explicit, independently-modeled sub-domains with clear integration contracts
- Entities vs. Value Objects — distinguishing identity-based objects (Eloquent models as Entities) from immutable, equality-based Value Objects (e.g., Money, Email, Address) in PHP
- Aggregates & Aggregate Roots — clustering related Entities and Value Objects behind a single transactional boundary, enforced through Laravel repositories
- Domain Events — capturing meaningful state changes in the domain layer and publishing them through Laravel's event system or a dedicated dispatcher
- Repositories — abstracting persistence behind domain-facing interfaces, keeping Eloquent out of the domain layer and enabling testable, swappable infrastructure
- Domain Services — encapsulating domain logic that doesn't naturally belong to a single Entity or Value Object
- Anti-Corruption Layers & Context Mapping — translating between Bounded Contexts (e.g., via Laravel HTTP clients, DTOs, or dedicated adapter classes) to prevent model pollution
- How would you define a Bounded Context for a Laravel e-commerce application, and where would you draw the line between the 'Catalog' and 'Ordering' contexts?
- What is the difference between an Entity and a Value Object in Evans's model, and how does PHP's type system (readonly classes, named constructors, strict_types) help enforce Value Object immutability in Laravel?
- Why should an Aggregate Root be the only entry point for modifying its cluster, and how do you enforce this constraint when Eloquent relationships can bypass it?
- How do Domain Events differ from Laravel's built-in application events, and what responsibilities belong in a Domain Event versus an Application Event listener?
- What is a Repository's contract in DDD, and how do you implement one in Laravel so that the domain layer never imports an Eloquent class directly?
- What is an Anti-Corruption Layer, and when would you introduce one between two Bounded Contexts in a Laravel monolith or microservice?
- Bounded Context Map: Draw a full context map for a sample Laravel SaaS app (e.g., multi-tenant project management tool). Identify at least four Bounded Contexts, label their relationships (Shared Kernel, Customer/Supplier, Conformist, ACL), and write one-paragraph Ubiquitous Language glossaries for each context.
- Value Object Library: Implement at least six PHP Value Objects (e.g., EmailAddress, Money, DateRange, UserId, Percentage, Slug) as PHP 8.2+ readonly classes with private constructors, named constructors, validation on creation, and full PHPUnit test coverage — zero Eloquent dependencies.
- Aggregate & Repository Pattern: Model an 'Order' Aggregate Root with OrderLine Entities and a Money Value Object. Write a Laravel-compatible OrderRepository interface in the domain layer and a concrete EloquentOrderRepository in the infrastructure layer. Wire them together via a Laravel Service Provider and verify the domain layer has no Eloquent imports.
- Domain Event Pipeline: Implement a PlaceOrder domain use-case that raises an OrderPlaced Domain Event. Dispatch it through a dedicated DomainEventDispatcher (not Laravel's Event facade directly in the domain). Write listeners in the application layer that send a confirmation email and update inventory, and write integration tests asserting both side-effects fire.
- Anti-Corruption Layer: Integrate a third-party shipping API (mock it with a fake HTTP response) into your Order context. Build an ACL consisting of a ShippingGateway interface, a concrete adapter, and a translator that maps the external payload to your domain's ShipmentDetails Value Object. Write unit tests for the translator in isolation.
- Hexagonal Architecture Audit: Take an existing Laravel project (or a fresh one) and perform a layer audit. Identify every place the domain logic touches the framework (facades, Eloquent, config(), etc.), refactor each violation using Ports & Adapters, and document the before/after in a short architectural decision record (ADR).
Next up: Mastering Evans's tactical and strategic patterns gives you the architectural vocabulary and structural discipline needed to apply advanced Laravel-specific patterns — such as CQRS, event sourcing, and modular monolith packaging — which build directly on the Aggregates, Domain Events, and Bounded Contexts established here.
The original DDD 'blue book' by Addison-Wesley — aggregates, value objects, bounded contexts, and ubiquitous language. At this stage you have enough Laravel fluency to map these concepts onto real application structure.
Discussion
Keep reading
Paths that share books, cover the same subject, or open a related topic.
