Domain-Modeling on Brian Faust

One Parcel Doesn't Have One Pricing Weight

Wed, 01 Apr 2026 00:00:00 +0000

A parcel weighs two kilograms. Its dimensions make its volumetric weight 4.8 kilograms. One service prices the larger measurement, rounded up to a whole kilogram; another prices actual weight. The same parcel gives those services pricing weights of five and two kilograms.

Calculating a weight once and sharing it across both candidates would save work. It would also calculate the wrong thing. The reusable fact is the parcel’s geometry, not whichever service’s policy happened to run first.

The Engine Prices Parcels, Not Copies

Sun, 01 Mar 2026 00:00:00 +0000

I dropped the package-copy shortcut during the rating engine’s development. If a shipment contained ten parcels, I wanted ten parcel records, not one record with copies: 10. Count-based pricing stayed. The alternative way of describing the things being priced didn’t.

This was an earlier input-model decision, not another change made during the Go port. It matters to the rest of the engine because parcels acquire references: a transport leg carries particular parcels, an item allocation belongs to a particular parcel, and a package-scoped rule needs that parcel’s facts. A multiplier doesn’t answer those questions without more conventions.

Not Every Pricing Rule Belongs in a Formula

Sun, 01 Feb 2026 00:00:00 +0000

The first parcel costs EUR 20. Parcels two through ten cost EUR 5 each. After that, each additional parcel costs EUR 3. Twelve parcels should cost 20 + 9 × 5 + 2 × 3 = 71 euros. There is nothing particularly exotic about that tariff. Turning it into three small programs still creates more work than the arithmetic suggests.

My first pricing model could express those programs. It knew about package scope, conditions, calculated amounts, and ordered adjustments. The problem wasn’t an inability to calculate the right price. It was that ordinary tariff structure kept arriving as another expression for the system to interpret. That affected editing, validation, and eventually execution.

How a Shipping Quote Gets Its Price

Thu, 01 Jan 2026 00:00:00 +0000

A parcel weighs two kilograms. The tariff has a price for two kilograms. Returning that price sounds reasonable. It can also be wrong before the lookup finishes: the tariff may charge for volume, the account may have a negotiated transport rate, and handling may apply to each parcel rather than once to the shipment.

I built a private logistics rating engine around those interactions. It stayed private rather than becoming a commercial product. What made it interesting was that most of the difficulty came from pricing itself. I could work on the model without first accommodating years of unrelated business exceptions. There was still plenty to get wrong.

A Primitive Can Hide a Domain Decision

Wed, 01 Apr 2020 00:00:00 +0000

Uppercasing a country code looks like normalization:

return mb_strtoupper($input);

It makes fi and FI equal. It also turns finland into FINLAND and leaves FIN looking plausible.

The string is tidier, not safer. The function has changed its shape without answering the domain question: is this a supported country identity in the representation this boundary promises? A primitive becomes expensive when every caller must remember that answer. The reason to introduce a domain type isn’t that strings are unfashionable. It is that the scalar no longer carries enough of the contract.

Time Zones Are Part of the Data Model

Thu, 01 Jun 2017 00:00:00 +0000

One metering path assigns an event to a billing month after converting its occurrence time into the account’s timezone. The same path derives its daily usage key directly from the occurrence timestamp without that conversion.

Near midnight, those two fields can disagree:

event instant: May 31, 21:30 UTC
local business time: June 1, 00:30
billing period: June
stored usage date: May 31

Each expression looks like an ordinary date calculation. They model different things, and the defect stays invisible until the difference crosses a day or month boundary.

Null Is a Domain Decision

Sat, 01 Apr 2017 00:00:00 +0000

We added four nullable fields to preserve a pricing snapshot: net amount, tax rate, tax amount, and gross amount. Each field could now be absent. That did not make each field independently optional.

For older records, all four nulls meant one thing: this record predates the snapshot and does not contain captured pricing evidence. For new records, all four values had to arrive together. A row containing gross and net but no tax rate was not “partly known.” It was invalid.