Compares traditional Laravel MVC with clean architecture and explains the 4-layer structure (presentation / application / domain / infrastructure), the dependency inversion principle (DIP), the directory layout, and the separation of the Eloquent model from the domain entity.
No Laravel experience required. A 20-chapter guide for SPA developers (Vue/React) that explains Laravel as an API backend together with domain-driven design (DDD) and clean architecture, step by step. It covers the theory of value objects, entities, aggregates, and repositories, through to implementation patterns, transactions, testing, and authentication in a Laravel project.
Explains the DDD aggregate (Aggregate) using the Order aggregate as the example. It covers why the aggregate root is the sole access point, how to decide aggregate boundaries (lifecycle / consistency / transaction / references), choosing between immediate and eventual consistency, referencing across aggregates by ID, and the idea of snapshots.
Explains the design of authentication and authorization in DDD and clean architecture. Covers the division of responsibilities where authentication lives in the presentation layer and authorization in the application and domain layers, the structure of JWT, the implementation with Laravel × tymon/jwt-auth, access/refresh tokens, and role-based authorization.
Organizes the key points of all 20 chapters of this guide (DDD tactical design / clean architecture / practical techniques / a comprehensive hands-on example), and summarizes a roadmap for incremental adoption—value objects → use case layer → repository → domain events—along with frequently asked questions and recommended books, communities, and learning paths.
Explains the design of the presentation layer that handles HTTP requests/responses. Covers format validation with FormRequest, the division of responsibilities with the domain layer, conversion to Commands, thin controllers, API Resources, middleware authentication, and Policy authorization.
Explains the design of the application layer (use case layer). Covers its responsibilities of coordinating domain objects, managing transactions, and converting input/output; Command / Query separation based on the CQS principle; Command objects and DTOs; dedicated Query services; and design guidelines such as single responsibility.
Explains the DDD domain event (Domain Event) with implementation examples such as OrderConfirmed. It covers loose coupling through event-driven design, the two-phase implementation of recording and dispatching, integration with Laravel Events, synchronous vs asynchronous (ShouldQueue), and the design of idempotency and eventual consistency.
Covers why to design domain-model-first, mapping patterns under the premise that the domain model and tables are not 1:1 (embedding / one aggregate across multiple tables / technical splitting), how the repository absorbs the gap, and index design including the leftmost-prefix rule for composite indexes and its trade-offs.
Explains the DDD domain service (Domain Service) with implementation examples of discount calculation, stock allocation, and shipping-fee calculation. It covers the criteria for placing logic that spans multiple aggregates and has no infrastructure dependency, the difference from use cases (application services), and design guidelines for avoiding an anemic domain model.
Explains the DDD entity (Entity) with implementation examples of Order / OrderLine. It covers identity judgment by identifier, the difference from value objects, entity ≠ table, the two factory methods create() / reconstruct(), and state transitions and the encapsulation of business rules using enums.
Explains error handling in a DDD architecture. Covers an exception hierarchy organized per aggregate, the design of DomainException, mapping to HTTP statuses (404/409/422, etc.) in the Exception Handler, a unified error response, the Result type pattern, a logging strategy, and protecting sensitive information.
An introduction to DDD and clean architecture with Laravel, aimed at developers experienced with SPA development (Vue/React). It covers who this guide is for, prerequisites, the 20-chapter structure, and an overview of DDD and clean architecture.
Integrates the DDD and clean architecture learned so far, implementing the 4 layers (presentation / application / domain / infrastructure) using the order creation and confirmation APIs as the subject. Summarizes each layer's responsibilities, the flow of data transformation, and layered tests (domain / UseCase / Repository) to bring the whole picture together.
Explains the testing strategy for a DDD architecture. Covers the idea of the test pyramid (Unit / Integration / Feature), the benefit of testing the domain layer fast without a DB, minimal use of mocks, Arrange-Act-Assert, descriptive test method names, and the test data builder pattern.
Organizes the core DDD terminology. It explains the definitions of domain / domain object / domain model / business rule, the difference between an entity and a value object, the roles of aggregates and repositories, and the ideas of the ubiquitous language and the bounded context, with concrete examples.
Implements the repository pattern with Laravel + Eloquent. Covers why the interface lives in the domain layer (DIP / testability), one aggregate = one repository, mapping between entities and Eloquent Models, the N+1 problem and eager loading, mass-assignment protection, and registration in the DI container.
Explains transaction management using Laravel's DB::transaction(). Covers the ACID properties, when to place transactions inside the Repository (single aggregate) versus the UseCase (multiple aggregates), nested transactions (savepoints), and the implementation and use cases of optimistic and pessimistic locking.
Explains the DDD value object (Value Object) with implementation examples such as Money / EmailAddress / ShippingAddress / OrderId. It summarizes their advantages over primitive types, the importance of immutability, and design guidelines for named constructors, validation, and equals().
Organizes the problems that arise when handling complex business logic in traditional Laravel MVC—Fat Controller, Fat Model, and scattered logic—and explains the four benefits gained by adopting DDD: clarifying business rules, resilience to change, testability, and team communication.