Ubiquitous language and bounded contexts

DDD starts with two ideas, and both are about words. Get the words right and a surprising amount of design falls out for free.

The first is the bounded context: a boundary inside which a set of terms has exactly one meaning. Outside the boundary the same word can mean something else. "Customer" in a billing context and "Customer" in a support context are different models with different rules, and pretending they're the same is how systems rot. A bounded context says: inside here, these nouns and verbs mean precisely this.

The shift from your Nest habits is subtle but important. In Nest you already draw boundaries: a module, a package, a service. But those are usually tech boundaries (the auth module, the notifications service). A bounded context is drawn around a piece of the business, not a piece of the stack. The tech layers live inside the context.

The second idea is the ubiquitous language: the vocabulary everyone inside the context uses, identically, everywhere. The code, the tests, the JIRA tickets, and the standup conversation all use the same word for the same thing. No translation layer between "what the business calls it" and "what the variable is called."

You've felt the absence of this. It's the codebase where a Passenger in the database is a pax in the ticket and a Customer in the service and a traveller in the frontend, and every boundary needs a little mental map. A ubiquitous language deletes those maps. When a domain expert who can't read code would still recognise your nouns and verbs, you have one.

Here's why this is more than tidiness. In DDD the name is part of the model, so a precise name can carry a domain rule. Take flight identity. Fusion addresses a flight by its unique_flight_key, not by its bare flight number. Why? Because two co-numbered legs (EZY715 outbound and EZY715 return on the same day) share a flight number but are different flights and different disruptions. Deciding or annotating one must not silently touch the other. The unique key distinguishes them, so the identifier itself prevents the confusion. That's a bug class eliminated by a naming choice.

Hold onto this: everything that follows (value objects, aggregates, the layering) is in service of keeping one model coherent inside one boundary, with one language. When you see EjdpUniqueFlightKey in fifty files instead of flightNumber in some and flight_id in others, that's the language being ubiquitous, and it's load-bearing.