Filament UI

Filament is an optional Laravel admin delivery mechanism under {Module}/UI/Filament/. It is not Domain and not a shortcut around Use Cases.

Placement

Ordering/UI/Filament/
├── Resources/
│   └── Orders/
│       ├── OrderResource.php
│       └── Pages/
├── Actions/          # optional custom actions
└── …

Rules

Allowed	Forbidden
Filament Actions / pages call first-level `*UseCase`	Business policy only inside `mutateFormDataBeforeCreate` without a Use Case
Map form state → Application DTO	Injecting peer `*ModuleInterface` into Resources
Present Domain results / exceptions as notifications	Using Eloquent models from another module to decide eligibility
Standard CRUD that still goes through Use Cases when policy exists	Cross-module Eloquent joins for “convenient” admin tables

Action pattern (illustrative)

// UI/Filament — delivery only
Action::make('fulfill')
    ->requiresConfirmation()
    ->action(function (OrderModel $record) {
        ($this->markOrderFulfilled)(new MarkOrderFulfilledDTO(
            orderReference: $record->getReference(),
        ));
    });

Prefer resolving the Use Case via the container / constructor injection on the Page or Action class — same entry-point rules as Controllers.

Forms and tables

Validate shape in Filament (required, max length, types).
Encode policy in Domain / Use Cases.
List subheadings and empty states should use professional, usage-oriented English (operator-facing), not internal architecture jargon.

Error handling

Catch Domain exceptions in the UI layer and map them to Filament notifications. Do not swallow replaceability-breaking imports to “get a friendlier message” from a peer module’s Domain.

Wave note

Deeper Filament Builder / navigation recipes may grow here later; Core entry-point and ACL rules already apply today.

Core reference: Golden flow · Use cases & DTOs.