Freight consolidation system — 60 classes, no hand-written business logic

Showcase
1

Promised I would post this once it stopped embarrassing me. It has.

What it does: consolidates part-load freight from multiple shippers into full containers,
prices each shipper’s share, and tracks the container through customs to final delivery.

The model: around 60 classes. The interesting part is that the consolidation rules —
which shipments can share a container, based on destination, hazard class, temperature
requirements and delivery window — are entirely OCL. There is no hand-written business logic
in the system at all.

What surprised me: the pricing rules changed four times during the build, twice after we
had “finished”. Each change took under an hour because it was one derived attribute and a
constraint, not a service class with tests around it.

What was hard: the state machine for a container that can be partially unloaded and
reconsolidated mid-route. Took three attempts. The composite-state advice from
an earlier thread here is what finally unstuck it.

Happy to answer questions about any of it.

2

Sixty classes with no hand-written logic is genuinely impressive. What did you do about the customs integration — is that OCL too, or does it sit outside?

3

Outside. Customs is a SOAP endpoint with its own idea of reality, so there is an integration layer that translates and a class that holds the response. The model never talks to it directly.

4

This is the pattern we should be documenting: model owns the rules, integration owns the mess, and there is a clear line between them. Would you write that up as its own topic?

5

I will. Give me a week to make the diagram presentable.