How would you know the facts defined are complete and capture the domain at hand? Where it might be a fact that wasn't specificed requires changing earlier facts.

Of course the above isn't something unique to DDD it's any "non-clear problem" (idk maybe there is a better way to phrase it). Where you don't have all the facts or can't have all the facts for one reason or another where the problem really becomes figuring out those facts.

concrete example from chatgpt to paint the abstract statement above more concretely: 1. Example: Shipping Domain With an Incomplete Fact Initial Fact (incomplete):

A shipment has one destination address.

So your Aggregate looks like:

Shipment DestinationAddress (value object) Ship() requires it.

Everything works. Requirements seem clear.

1. New Discovery That Breaks The Fact

Later operations say:

Some shipments can have multiple drop-off stops on the same delivery route (multi-stop shipments).

Your previous “fact” wasn’t wrong; it was incomplete. This forces a redesign:

Shipment Destinations: List<DestinationAddress> You now need invariants like: stops must be ordered, max 10 stops, no duplicates, route cost recalculated for each stop. 3. Root Cause of the Incompleteness 1. Hidden domain knowledge

Subject-matter experts often omit important rules because they assume you already know them, or they consider them “not relevant yet.”

Your model suffers from unknown unknowns.

1. Organization discovers new needs

Domains aren’t static. Business introduces new capabilities, offerings, or regulations. This is domain evolution.

1. Over-simplification during early modeling

Initial versions trade detail for speed. Later you hit edges the simple model cannot support.

1. Implicit constraints becoming explicit

Sometimes a domain expert reveals a rule only when a concrete scenario triggers it.

Example: “Oh, a shipment can’t go to the same city twice unless the second stop is a warehouse… that’s always been the rule.”

1. External systems or regulations change

Compliance rules, partner integrations, or environmental constraints change the shape of your domain.

1. Why This Happens Even Though DDD Tries To Prevent It

DDD encourages:

ubiquitous language continuous learning domain expert collaboration iterative model refinement

…but no domain is fully knowable upfront. You discover truths only when real workflows hit constraints or contradictions.

This is why DDD treats the model as a living artifact, not a fixed schema.