Introduction to Domains

Learn how Obelaw structures enterprise applications using Domain-Driven Design (DDD) bounded contexts.

Introduction to Domains (DDD)

Obelaw Domains brings the principles of Domain-Driven Design (DDD) into modern enterprise architecture, organizing complex business logic into isolated, sovereign, and self-contained Bounded Contexts.

By segregating pure domain rules from delivery mechanisms (such as HTTP controllers, REST APIs, Filament administration resources, or console commands), Obelaw enables engineering teams to build software that directly mirrors, protects, and scales with business strategy.

1. Core Architectural Philosophy

Traditional enterprise applications frequently suffer from “fat models”, anemic services, and business rules leaking into HTTP controllers. Obelaw enforces a strict three-layer architecture:

flowchart TD
    subgraph Presentation["1. Presentation / Delivery Layer"]
        Controllers["HTTP Controllers"]
        Filament["Filament Resources"]
        Console["Console Commands"]
        Webhooks["Inbound Webhooks"]
    end

    subgraph Domain["2. Domain Layer (Pure Business Core)"]
        Gateways["Context Gateways"]
        Actions["Single-Purpose Actions (Writes)"]
        Queries["Fluent Queries (Reads)"]
        Invariants["Domain Invariants ('The Law')"]
        Aggregates["Aggregate Roots & State Machines"]
        Events["Domain Events Bus"]
    end

    subgraph Infrastructure["3. Infrastructure / Persistence Layer"]
        Storage["Relational Database Storage"]
        CacheStore["Distributed Cache"]
        ThirdParty["Third-Party Adapters & Ports"]
    end

    Presentation -->|"Validated DTOs"| Gateways
    Gateways --> Actions
    Gateways --> Queries
    Actions --> Invariants
    Actions --> Aggregates
    Aggregates --> Events
    Aggregates -.->|"State Persistence"| Storage
    Queries -.->|"Read Optimizations"| Storage

Presentation / Delivery Layer: Handles request parsing, authentication, routing, and packaging inputs into immutable Data Transfer Objects (DTOs). Contains zero business logic.
Domain Layer: The heart of the application. Contains pure business logic, validation rules, mutation actions, query pipelines, and state machines. It is completely decoupled from UI frameworks and web protocols.
Infrastructure / Persistence Layer: Manages database migrations, persistence storage, cache drivers, and external API gateways.

By isolating the Domain Layer, core business rules remain completely unaffected by database alterations, frontend UI redesigns, or framework upgrades.

2. Why Use Obelaw Domains?

Strict Context Isolation: Domains cannot bypass boundaries to modify each other’s internal database models. All cross-domain operations occur through explicit gateways or asynchronous event subscriptions.
CQRS Segregation: Read queries and write mutations are strictly separated into dedicated classes, preventing unintended side-effects and bloated god-objects.
Type-Safe Boundary Shields: Every payload entering or leaving a domain is enforced through immutable Data Transfer Objects (DTOs), guaranteeing data integrity.
Auditable & Reversible: State mutations are recorded in append-only audit trails. Post-commit corrections are executed through compensating transactions rather than destructive database deletes.
Zero Framework Monoliths: Domains are package-based, allowing organizations to adopt individual contexts or assemble the entire enterprise suite.

3. The Obelaw Bounded Context Suite

Obelaw organizes enterprise operations into specialized, production-ready bounded contexts. Each domain is documented with an 8-chapter architectural blueprint:

Domain	Strategic Type	Operational Scope	Blueprint Link
Product Information Management (PIM)	Core Domain	Canonical merchandise master, dynamic attribute schemas, variant option matrices, multi-tree taxonomies, and engineering BOM recipes.	Explore PIM Blueprint
Customer Relationship Management (CRM)	Supporting Domain	Prospect lead scoring, qualification pipelines, contact & account directories, opportunity forecasting, and support SLA tickets.	Explore CRM Blueprint
Financial Accounting & Ledger (FMS)	Generic Domain	General Ledger, Chart of Accounts, zero-sum double-entry journal vouchers, fiscal period governance, and financial trial balance statements.	Explore Accounting Blueprint
Inventory & Warehouse Management (WMS)	Core / Supporting	Spatial warehouse topology (Zone/Aisle/Rack/Bin), lot & serial tracking, reservation lifecycle, non-negative stock invariants, and cycle counts.	Explore Inventory Blueprint
Procurement & Purchasing	Supporting Domain	Vendor directory, RFQ-to-PO procurement pipelines, three-way matching (PO, GRN, Bill), landed cost allocations, and purchase returns.	Explore Purchase Blueprint
Sales & Order Management (OMS)	Core Domain	Omnichannel sales orders, real-time ATP stock reservation, price lock freeze, split fulfillment dispatches, and return authorizations (RMA).	Explore Sales OMS Blueprint
Manufacturing: In-House MRP	Core Domain	Work center routing, machine capacity planning, shop floor work order lifecycles, material issuance, scrap allowances, and finished output receipt.	Explore MRP In-House Blueprint
Manufacturing: Subcontracting MRP	Supporting Domain	Outwork job orders, raw material consignment dispatch (challans), contractor scrap/yield reconciliation, and outside processing service billing.	Explore MRP Subcontracting Blueprint
Point of Sale (POS)	Supporting Domain	Offline-first cash register checkouts, shift till float balance, optical barcode scanning buffers, split payments, and end-of-day reconciliation.	Explore POS Blueprint

4. Operational Operation Lifecycle

Every write operation follows a deterministic, invariant-guarded lifecycle:

sequenceDiagram
    autonumber
    participant Client as Presentation Layer (Controller / UI)
    participant DTO as Validated Input DTO
    participant Action as Domain Action
    participant Invariant as Domain Invariants ("The Law")
    participant Bus as Domain Event Bus
    participant ReadModel as Read Model / Downstream ACL

    Client->>DTO: Instantiate and validate payload
    Client->>Action: Execute action with DTO
    Action->>Invariant: Verify business constraints
    alt Invariant Violation
        Invariant-->>Action: Reject with DomainInvariantViolation
        Action-->>Client: Throw Exception (Transaction Aborted)
    else Invariant Verified
        Invariant-->>Action: Verification OK
        Action->>Action: Mutate Aggregate State & Persist
        Action->>Bus: Emit domain event(s)
        Bus-->>ReadModel: Asynchronously notify subscribers
        Action-->>Client: Return immutable Result DTO
    end

5. Next Steps

Review the Getting Started Guide to understand context setup and directory layouts.
Read the Domain Architecture Specification for details on CQRS and Event Bus mechanics.
Select a domain from the catalog above to inspect its tactical aggregate models, state machines, and business rules.