Skip to main content

11 docs tagged with "clean-architecture"

View all tags

A Practical Introduction to Laravel × DDD × Clean Architecture

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.

Aggregates — The Consistency Boundary and the Aggregate Root

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.

Conclusion and Next Steps — Introducing DDD Incrementally

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.

Designing the Use Case Layer — Command / Query Separation and DTOs

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.

Domain Services — Business Logic That Does Not Belong to an Entity

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.

In Practice: Implementing the Order System — An Example That Cuts Across All Layers

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.

Why DDD — The Limits of the Fat Controller / Fat Model

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.