DDD Architecture for Logistics Systems in PHP
Shipment tracking, freight management and warehouse orchestration need event-driven domains, not monolithic tables. Jardis gives your logistics system the architecture that models every status change as a domain event.
The More Carriers You Connect, the More Fragile the System Gets.
Logistics software starts as simple tracking. Then come new carriers, warehouse management, EDI interfaces. Without domain boundaries, every integration becomes a liability.
Tracking data stuck in silos
TMS, WMS and carrier APIs deliver status updates in different formats. Without central domain events, shipment statuses are inconsistent. Customers see stale data, dispatchers make decisions on wrong information. Last-mile tracking and cross-docking statuses run through separate systems that do not know about each other.
Status transitions get lost
Pickup, transshipment, customs clearance, delivery: every step changes a shipment's status. Without event-driven architecture, transitions are direct database updates. Gaps in tracking are inevitable. In multi-modal transports switching between truck, rail and sea, entire segments of the shipment history go missing.
Every carrier integration is a custom project
New carriers, EDI protocols or API versions require weeks of integration work. Business logic is tangled with adapter code. Switching a carrier pulls changes through half the codebase. Whether EDIFACT for international freight or REST APIs for last-mile services, every integration is built from scratch.
Tracking events instead of database polling.
The Jardis Builder generates event-driven domains for every part of your supply chain. Tracking, Routing and Warehouse as standalone Bounded Contexts with physical separation.
Every shipment status becomes a domain event
ShipmentCreated, PickedUp, InTransit, CustomsCleared, Delivered: the builder generates events and handlers for every status transition. No direct database updates, no lost statuses. Every change is traceable and auditable. In multi-modal transports, every carrier handoff publishes its own event, so the complete transport chain is documented without gaps.
Carriers as swappable adapters
The Ports & Adapters architecture separates carrier integrations from domain logic. DHL, FedEx, local carriers: each gets its own adapter. Switching a carrier only affects the adapter, not the business logic. EDIFACT for international freight, REST for last-mile services and SOAP for legacy carriers coexist in the same system without mutual dependency.
Tracking, Routing and Warehouse as separate packages
Each Bounded Context becomes a standalone PHP package. The warehouse system cannot access routing tables. The builder enforces this separation at the filesystem level. TMS and WMS logic stay cleanly separated, even when they collaborate. Customs handling, warehouse management and route planning as independent contexts, connected through domain events.
See what three files turn into.
Three definition files in, a complete bounded context out. Browse the generated code.
# Database Schema — Sales Bounded Context
# This file defines the persistent storage structure.
schema:
domain: ECommerce
boundedContext: Sales
tables:
order:
columns:
id:
type: integer
primary: true
autoIncrement: true
public_id:
type: uuid7
unique: true
customer_email:
type: string
length: 255
status:
type: string
length: 32
default: "draft"
total_amount:
type: integer
currency:
type: string
length: 3
default: "EUR"
created_at:
type: datetime
updated_at:
type: datetime
nullable: true
order_item:
columns:
id:
type: integer
primary: true
autoIncrement: true
order_id:
type: integer
foreignKey:
table: order
column: id
onDelete: cascade
product_name:
type: string
length: 255
sku:
type: string
length: 64
quantity:
type: integer
unit_price:
type: integer
line_total:
type: integer
What Logistics Teams Gain with Jardis.
From local shipping to international supply chains. Jardis grows with your infrastructure.
The Supply Chain as an Event Stream
Every step in the supply chain publishes a domain event. Downstream systems react automatically: update inventory, notify customers, alert dispatchers.
Switch Carriers Without Rewriting Code
Hexagonal architecture separates carrier APIs from routing logic. New carrier? Write the adapter, plug it in. Domain logic stays unchanged whether you use EDI, REST or SOAP.
Teams Own Domains, Not Features
One team owns tracking. Another owns warehouse management. Deployments are independent because physical package boundaries define responsibility.
How long should your shipment statuses travel by database update?
Join the WaitlistStructure costs less than chaos.
Try Jardis 7 Days Free
Point Jardis at your real domain. Discovery, structure, and your first platform build.
Join WaitlistThe complete DDD architecture with all classes and contracts. Your team ships features, not infrastructure.
Join WaitlistThe complete business logic with handlers, validation, and pipelines. What used to be a sprint is now a build.
Join WaitlistMore than 20 Platform Builds per month?
Let's talkBe there when Jardis launches.
Sign up. You'll get access as soon as we go live. Including a free trial.
Curious how Jardis works?
Discover JardisFrequently Asked Questions
Answers to the most important questions about Jardis in the logistics context.
Yes. Jardis is built for brownfield scenarios. You generate individual Bounded Contexts and integrate them step by step into existing PHP systems. The Ports & Adapters architecture ensures new domains can run alongside existing TMS or WMS code. A typical entry point: tracking as its own context, delivering status data to the existing TMS via domain events.