WINCHHandbook
DDD

Domain Glossary

Roughly forty bounded contexts live under `src/Domain/`. This glossary names each one and describes its responsibility in a sentence or two so you can pattern-match against the right place when something new needs to land. When a description is marked **TODO**, the owning team should fill it in — better to leave a marker than to guess.

For a numeric snapshot of each domain's DDD adherence and legacy footprint, see the DDD Map.

Core and shared

  • Core — shared abstracts, traits, and base classes used by every other domain: FilterData, GetDataAbstract, Arrayable, the ProjectFlavor and FeatureFlag enums. The first place to look before adding a new utility.
  • UserCore — base user identity and shared user-account behaviour underneath the user-type panels.

Order flow

  • Order — customer-placed orders, the central transaction the rest of the operational flow revolves around.
  • Quotation — quotations issued to customers, often the predecessor of an Order.
  • Rental — rental contracts and the state machine around active and returned rentals.
  • Waybill — issued waybills attached to orders, used as the physical record for transport.
  • InternalOrder — internal-only orders that don't surface to the customer-facing flow.
  • Provider — third-party service providers that fulfil orders.
  • Owner — vehicle and asset owners that providers represent.

Financial

  • Accounting — the ledger: recorded transactions for orders, rentals, transfers, and adjustments.
  • Bank — bank account records and transfer destinations.
  • MoneyTransfer — transfers between accounts.
  • FixedPrice — fixed-price catalogue entries used in quotations and orders.

Fleet management

  • FleetManagement — fleet-level operations covering vehicles, drivers, and maintenance scheduling.
  • PredefinedAsset — catalogue of predefined assets that can be assigned into a fleet. TODO: confirm exact scope with the FleetManagement owner.

Identity, roles, and security

  • Employee — staff records, including admin and back-office personnel.
  • Role — role definitions used by the permission system.
  • Security — security-related concerns: login, OTP, account locking, audit. TODO: confirm exact responsibilities — overlap with UserCore is worth documenting explicitly.
  • Admin — back-office admin-user concerns specific to the Admin presentation panel.

Communication and content

  • Message — in-app messages between users.
  • Comment — comments attached polymorphically to other entities.
  • Banner — promotional banners shown in the customer-facing apps.
  • Activity — activity-log entries describing what changed and who changed it.

Support and attachments

  • Attachment — polymorphic file attachments. Any entity can morphMany(Attachment::class, 'attachable').
  • FileArchive — long-term archival of files. TODO: confirm retention policy and relationship to Attachment.
  • Category — generic category taxonomy used across multiple domains.
  • Location — geographic locations (cities, regions, addresses) used in orders, providers, and customers.
  • Nationality — nationality lookup data.
  • Establishment — establishment / company records used in user onboarding.
  • Company — corporate customer records. TODO: clarify the relationship between Company, Establishment, and Customer.

Operations and admin

  • Setting — application-wide settings stored in the database.
  • Module — application module / feature toggles tied to the menu. TODO: confirm relationship to Pennant flags and ProjectFlavor.
  • WinchBranch — Winch operational branches; the winch_branches feature is gated behind a Pennant flag.
  • Exporter — orchestrates large CSV / Excel exports across multiple domains.
  • Integration — third-party integration glue (external APIs, webhooks). TODO: list which integrations live here vs. in app/.

Workflow and process

  • Approval — multi-step approval flow used by request types that need supervisor sign-off. TODO: list which entities use Approval today.
  • AttemptProcess — process / attempt tracking for operations that retry. TODO: confirm scope.
  • AddDataRequest — requests to add new reference data (cities, nationalities, etc.) that route through an approval workflow.
  • ChangeDataRequest — requests to amend existing reference data that route through an approval workflow.

Other

  • Ai — AI-assisted features in the product. TODO: describe which features and which models.
  • Leave — employee leave management. TODO: confirm whether this is HR-leave or something else.
  • Supply — supply / supplier records. TODO: describe responsibilities.
  • UserContract — user-facing legal contracts (terms of service, privacy policy versions, signed agreements).
  • FavoritePage — user-bookmarked pages in the admin panel.

When to add a new domain

A new domain is a bigger commitment than it looks: a Contract, a Service, a Provider, an entry in bootstrap/providers.php, plus the conceptual cost of one more bounded context for everyone to keep in their head. Before adding one, check whether the concept fits inside Core, UserCore, or an existing context. If it really is new, follow the procedure in DDD overview.

Communication

The three sanctioned shapes for calling another domain — direct Contract call, event, queued job — and the rule for picking the right one.

Actions

How to write Actions — the smallest reusable unit of business logic in the codebase — and the rules that keep them consistent and safe.