Introduction to Domains (DDD)

Obelaw Domains brings the principles of Domain-Driven Design (DDD) into Laravel, allowing you to organize your business logic into isolated, self-contained modules.

By segregating domain rules from delivery mechanisms (like HTTP controllers, API requests, or Console commands), Obelaw helps you build systems that are easy to maintain, test, and scale.

Core Philosophy

Traditional Laravel applications often suffer from “fat models” or business logic leaking into controllers. Obelaw enforces a strict three-layer architecture:

1. Presentation / Delivery Layer: Controllers, Filament resources, Livewire components, or Console commands. This layer only handles request parsing, authentication, and passing DTOs to the domain.
2. Domain Layer: The heart of your application. Contains pure business logic, validation rules, operations (Actions), and query pipelines (Queries).
3. Infrastructure / Persistence Layer: Database tables, external API integrations, and low-level Eloquent models.

By isolating the Domain Layer, your business rules remain completely unaffected by changes to your frontend frameworks, database structures, or UI libraries.

Why Use Obelaw Domains?

• Strict Isolation: Domains cannot access each other’s internal database models or actions directly. All cross-domain communication goes through explicit gateway interfaces.
• CQRS-Lite: Read queries and write mutations are strictly separated into different classes, preventing bloated methods and side-effects.
• Type-Safe Boundaries: Domain inputs and outputs use immutable Data Transfer Objects (DTOs), guaranteeing data consistency.
• Zero Framework Bloat: Use only what you need. Domains are package-based, meaning you can drop them into any Laravel app.

Next Steps

Explore how to set up your first domain, or dive deep into the DDD structure:

• Getting Started
• Domain Architecture