Reference

DDD Map

Every domain in the backend with a one-line purpose, legacy-code estimate, and DDD adherence score. Use this page to spot which domains are mid-refactor and which to use as templates.

A snapshot inventory of every bounded context under src/Domain/ on master, paired with two heuristic scores. Use the table to spot exemplary templates worth copying from and the domains that still drag a long legacy tail behind them.

What this map is (and isn't)

This is a snapshot estimate, not an authoritative scorecard. Both percentages are computed from the file tree, not from reading the code. A domain with 90% DDD adherence can still have ugly internals; a domain with 30% legacy can still be the most-loved part of the system. Treat the numbers as a starting point for a conversation, not a final verdict.

Legacy code % — proxy for "how much of this domain still lives outside the DDD layout". Computed by looking for files that name-match the domain in the legacy locations (app/Http/Controllers/, app/Http/Controllers/Cp/, app/Models/ — which in this repo actually live directly under app/ — and matching database/migrations/), then comparing that count to the file count inside src/Domain/{Name}/. Where exact counting was impractical (rate limits, ambiguous matches), the value is bucketed and marked with .

DDD adherence % — heuristic based on the canonical subfolder layout. Each domain earns points for presence of Actions/ (+20), Services/ (+15), Contracts/ (+15), DataTransferObjects/ (+10), Models/ (+10), Providers/ (+10), plus up to +10 for any combination of Jobs/, Observers/, Notifications/, Mails/, Events/. A registered service provider in Providers/ is assumed when the folder exists. Note: this repo uses DataTransferObjects/ (not DataObjects/) — the points still apply.

The team should refine these numbers over time. When you do a refactor sweep on a domain, update its row.

The map

All 43 domains under src/Domain/ on master are listed. Sorted alphabetically.

Domains
43
Avg DDD
81%
DDD ≥ 85
14
Clean (legacy ≤ 10%)
27
Heavy legacy (> 30%)
6
Legacy
Accounting

The ledger: recorded transactions for orders, rentals, transfers, and adjustments.

≈30-60%
90%
Activity

Activity-log entries describing what changed and who changed it.

≈30-60%
50%
AddDataRequest

Requests to add new reference data that route through an approval workflow.

<10%
80%
Ai

AI-assisted features in the product.

<10%
60%
Approval

Multi-step approval flow for request types that need supervisor sign-off.

<10%
80%
Attachment

Polymorphic file attachments — any entity can morphMany(Attachment::class, "attachable").

≈30-60%
80%
AttemptProcess

Process / attempt tracking for operations that retry.

<10%
80%
Bank

Bank account records and transfer destinations.

<10%
80%
Banner

Promotional banners shown in the customer-facing apps.

<10%
80%
Category

Generic category taxonomy used across multiple domains.

<10%
80%
ChangeDataRequest

Requests to amend existing reference data that route through an approval workflow.

<10%
80%
Comment

Comments attached polymorphically to other entities.

10-30%
85%
Company

Corporate customer records.

<10%
90%
Core

Shared abstracts, traits, base classes (FilterData, GetDataAbstract, Arrayable, ProjectFlavor, FeatureFlag).

0%
80%
Employee

Staff records, including admin and back-office personnel.

10-30%
85%
Establishment

Establishment / company records used in user onboarding.

<10%
80%
Exporter

Orchestrates large CSV / Excel exports across multiple domains.

<10%
90%
FavoritePage

User-bookmarked pages in the admin panel.

0%
80%
FileArchive

Long-term archival of files.

<10%
80%
FixedPrice

Fixed-price catalogue entries used in quotations and orders.

<10%
85%
FleetManagement

Fleet-level operations: vehicles, drivers, maintenance scheduling.

≈30-60%
90%
Integration

Third-party integration glue (external APIs, webhooks).

<10%
70%
InternalOrder

Internal-only orders that don't surface to the customer-facing flow.

<10%
80%
Leave

Employee leave management.

<10%
80%
Location

Geographic locations (cities, regions, addresses).

>60%
85%
Message

In-app messages between users.

<10%
90%
Module

Application module / feature toggles tied to the menu.

<10%
80%
MoneyTransfer

Transfers between accounts.

<10%
80%
Nationality

Nationality lookup data.

<10%
80%
Order

Customer-placed orders — the central transaction the rest of the operational flow revolves around.

10-30%
85%
Owner

Vehicle and asset owners that providers represent.

<10%
85%
PredefinedAsset

Catalogue of predefined assets that can be assigned into a fleet.

<10%
70%
Provider

Third-party service providers that fulfil orders.

10-30%
85%
Quotation

Quotations issued to customers, often the predecessor of an Order.

10-30%
80%
Rental

Rental contracts and the state machine around active and returned rentals.

<10%
85%
Role

Role definitions used by the permission system.

10-30%
80%
Security

Login, OTP, account locking, audit.

10-30%
80%
Setting

Application-wide settings stored in the database.

10-30%
80%
Supply

Supply / supplier records.

<10%
80%
UserContract

User-facing legal contracts (terms of service, privacy policy versions, signed agreements).

<10%
80%
UserCore

Base user identity and shared user-account behaviour underneath the user-type panels.

>60%
80%
Waybill

Issued waybills attached to orders, used as the physical record for transport.

10-30%
85%
WinchBranch

WINCH operational branches; the winch_branches feature is gated behind a Pennant flag.

10-30%
80%
  • Accounting (90) — full layout, Jobs/, Observers/, Traits/. Reach for it when you need a domain with money, audit trails, and side effects.
  • FleetManagement (90) — full layout plus Observers/, Jobs/, Exceptions/. Good template when the domain has many models and state transitions.
  • Message (90) — full layout including Mails/ and Jobs/. The template for any communication-shaped domain.
  • Exporter (90) — full layout including Abstracts/, Jobs/, Exports/. Good template for orchestration domains.
  • Company (90) — full layout including Observers/ and Jobs/. Solid mid-sized template.
  • Order (85, 17 actions) — biggest action surface; copy patterns from here when you need a transaction-heavy domain.
When in doubt, copy the directory shape of Accounting or Order, then prune what you don't need.
  • Location — Address, City, Country, Region all still in app/. Multiple Cp/ controllers. Touched by almost every order — refactoring here unlocks downstream cleanup.
  • UserCoreapp/User.php still lives in the legacy tree, along with verification, change-avatar, change-me, and the matching Cp/ controllers. The most foundational migration left.
  • Attachment — polymorphic and used everywhere, with several attachment-type controllers and document-type models still in app/. Hard to refactor in isolation.
  • Roleapp/Role.php, app/Permission.php, and the role / bulk-permission controllers still outside. Permission system rework is a prerequisite.
  • Activity — DDD adherence is also low (50) — missing Actions/, DataTransferObjects/, Enums/. Both legacy and incomplete on the DDD side.
These five together account for the majority of the legacy footprint. Pick one when planning a quarter's worth of refactor work — don't try to do them all at once.

When to update this map

  • After any refactor that moves a class out of app/ into src/Domain/{Name}/.
  • When a new domain is added to src/Domain/ (also update the domain glossary).
  • When a domain's subfolder layout changes meaningfully (e.g. Actions/ added, Observers/ introduced).
  • At least once a quarter, run a quick pass and re-score the rows that have seen significant change.

Before claiming a domain is "fully migrated"

  • No files matching the domain name remain in app/Http/Controllers/ or app/Http/Controllers/Cp/.
  • No Eloquent model files for the domain remain directly in app/.
  • No helper / trait / package for the domain remains in app/Packages/, app/Traits/, or app/Constants/.
  • All routes for the domain are wired through the domain's own service provider (registered in bootstrap/providers.php).
  • Migrations created since the move follow the domain's table naming convention.
  • The domain glossary and this map have been updated to reflect the new state.