IUM

Your entire business, behind one fluent API.

A decoupled business domain builder for Laravel. Business logic is isolated from presentation — domains like EAM, PIM, and WMS are reached through a single fluent API. No HTTP routes, JSON schemas, or frontend contracts. Pure backend domain orchestration.

$ composer require obelaw/framework
Get Started View on GitHub 
// One fluent API — every domain, every call
$products = ium()->pim()->products()->list();

// Write and read stay strictly segregated
$product = ium()->pim()->product()->create(ProductData::from($payload));

IUM by numbers

1
Fluent API
4
Isolated Domains
0
HTTP Routes
9
DDD Layers

What is IUM?

Every domain, behind one fluent API.

Business logic lives in isolated domains — EAM, PIM, URL, WMS — and is orchestrated through one chainable interface.

One Fluent API

Every domain is orchestrated through a single chainable interface — one way in, one way to call anything.

ium() → domain() → service() → method()

Domains Stay Isolated

Each domain is a self-contained package with its own manager, actions, queries, and models. Domains can't reach into each other's internals — they only talk through the gateway.

EAM
PIM
URL
WMS

Persistence-Only Models

Eloquent models hold data, never business rules. Domain logic lives in validated DTOs, write actions, and read queries — keeping every layer thin and testable.

DDD-Aligned Packages

Each domain ships with actions, queries, DTOs, models, managers, events, and exceptions — writes and reads strictly separated.

Cross-Domain by Design

Wire PIM to WMS, or EAM to any consumer — the single gateway keeps integrations explicit and testable.

What IUM is not

Not an HTTP framework — no routes, controllers, or JSON contracts.
Not a UI framework — no blades, components, or frontend bindings.
Not a monolith — each domain ships as its own package you opt into.
A Fluent API DSL

One fluent API for every domain.

Every domain is orchestrated through one consistent, chainable interface — one way in, one way to call anything. 

$assets = ium()->eam()->assets()->available();
$products = ium()->pim()->products()->list();
$url = ium()->url()->shorten(ShortenUrlData::from([// ...]));
DDD-Aligned

Your domain, laid out layer by layer.

Each domain follows a DDD-aligned structure with strict segregation between write mutations and read pipelines. 

src/
├── Actions/
├── Data/
├── Events/
├── Exceptions/
├── Managers/
├── Models/
├── Providers/
├── Queries/
└── Traits/
Directory Concern
Actions/ Write mutations. Receives a validated DTO, performs one unit of work.
Queries/ Read pipelines. Intermediate methods return $this; terminal methods materialize results.
Data/ Immutable DTOs. Type-safe, structured input at every domain boundary.
Models/ Eloquent definitions. Persistence only — no business logic. Extends ModelBase (auto-prefixes ium_ tables, binds configured connection).
Managers/ Domain entry points. Orchestrates sub-services (AssetManager, CategoryManager, ReportsManager).
Events/ Domain events fired during lifecycle transitions.
Exceptions/ Domain-specific exceptions for invalid states.
Traits/ Cross-cutting model behaviors (HasAssets, HasMedia, HasStock).
FAQ

Questions, answered.

Everything you need to know about how IUM structures business domains.

Is IUM an HTTP framework or a REST API?
No. IUM is a backend domain-orchestration layer — it exposes no routes, controllers, or JSON contracts. Domains are reached directly from PHP through the fluent ium() gateway, so you stay free to expose them however you like: HTTP, CLI, queue jobs, anything.
How do domains stay isolated from each other?
Each domain ships as its own package with its own managers, actions, queries, and models. Domains never reach into each other's internals — cross-domain calls happen through the gateway, which keeps integrations explicit, decoupled, and testable.
What's the difference between Actions and Queries?
Actions are write mutations — they receive a validated DTO and perform one unit of work. Queries are read pipelines: intermediate methods return $this to stay chainable, and terminal methods materialize the result. Writes and reads never mix.
Do IUM models replace Eloquent?
No — IUM sits on top of Eloquent. Models are persistence-only definitions that extend ModelBase, which auto-prefixes ium_ tables and binds the configured connection. Business rules stay out of the models entirely.
Can I use IUM inside an existing Laravel app?
Yes. Drop in obelaw/framework via Composer and opt into the domains you need. IUM is designed to live alongside your existing Laravel code, not replace it.
Does IUM ship with a UI?
No. IUM is not a UI framework — no blades, components, or frontend bindings. Because domains are exposed through the fluent API, any frontend (Laravel Blade, Filament, a SPA, or an API wrapper) can consume them without touching your business logic.
Documentation

Pick up where the code left off.

Dive into the docs and start building your first isolated domain.

Introduction

What IUM is, what it isn't, and how it fits into your Laravel application.

Read the docs

Getting Started

Installation, setup, and configuration — stand up your first domain in minutes.

Read the docs

Available Modules

PIM, WMS, OMS, CRM, EAM, and URL — explore each domain in detail.

Read the docs

Ready to build your business domains?

Start orchestrating your business domains through a single fluent API today.

$ composer require obelaw/framework
Read the Docs View on GitHub