CHAPTER EIGHT

LDD and DDD

“DDD discovered language. LDD designs it.”

The Question I Get Asked All the Time

Is this just Domain-Driven Design with a new name?

Fair question. I get asked this all the time. Usually at conferences. Usually by someone who has read the blue book and wants to know if I am wasting their time.

I used to get defensive. I would list differences. I would draw diagrams. I would explain that LDD is not DDD, it is something else, something new, something you have not seen before.

That was a mistake. Not because the differences are not real. Because the relationship is more interesting than a list of bullet points.

Let me tell you what DDD did. Then let me tell you what DDD did not do. Then let me tell you why that gap matters and how LDD fills it.

What DDD Discovered

Domain-Driven Design gave us one of the most important ideas in modern software architecture. Ubiquitous Language.

Before DDD, we talked about domain models. We talked about object-oriented design. We talked about repositories and factories and services. But we did not talk about language. Not really. Not as a first-class concern.

Eric Evans changed that. He said that domain experts and developers should speak the same language. That the language should be in the code. That the code should be the language. That was a radical idea. Still is.

DDD discovered that language matters. That the words you use shape the models you build. That if the words are wrong, the models will be wrong. That discovery changed how we think about software.

I owe DDD a debt. Everyone who works in this space owes DDD a debt. The blue book is on my shelf. It is worn. It has sticky notes. I still read it sometimes.

But discovery is not the end. Discovery is the beginning.

What DDD Did Not Do

DDD discovered language. But DDD did not study language. Not deeply. Not systematically.

DDD uses language as a tool for modeling. You discover the Ubiquitous Language. You write it down. You put it in your code. You move on to the model.

The assumption is that once you have discovered the language, you can mostly leave it alone. That is not true. Language is never done. Language is always drifting. Always changing. Always accumulating debt.

DDD treats language as a modeling tool. A means to an end. The end is the model. The language is just how you get there.

LDD treats language as a design material. Something you shape. Something you refine. Something you govern. Something you close. The language is not just how you get to the model. The language is part of what you are designing.

Let me say this differently.

DDD discovered language. LDD studies language. DDD uses language. LDD designs language. DDD treats language as a modeling tool. LDD treats language as a design material.

This is the difference. DDD says, find the language, then build the model. LDD says, design the language, and the model will follow. LDD is not a replacement for DDD. A shift in attention. A different question.

The Gap DDD Left Open

Here is the gap that DDD left open. DDD tells you that language matters. It does not tell you how to keep language from decaying.

DDD tells you to use Ubiquitous Language. It does not tell you how to detect when the language is no longer ubiquitous.

DDD tells you to model the domain. It does not tell you how to refactor the language when the domain changes.

DDD tells you that different contexts have different models. It does not tell you how to discover where those contexts actually are. It assumes you can see them. Often you cannot. The language hides them.

DDD tells you to use Bounded Contexts. It does not tell you that the boundaries should come from the language, not from team structure or technical convenience.

These are not criticisms of DDD. The blue book is already long. Evans could not write about everything. No book can.

But the gap is real. And the gap is where Semantic Debt lives. The gap is where languages drift. The gap is where systems die. The fintech company died in this gap. The logistics company died in this gap. The healthcare company died in this gap.

They did DDD. They had Ubiquitous Language. They had Bounded Contexts. They had Event Storming workshops. They still died. Because DDD helped them discover the language. It did not help them keep it alive.

LDD is an attempt to fill that gap. To answer the questions DDD leaves open. How do you keep a language healthy over time? How do you close it? How do you govern it? How do you refactor it? How do you split a word that has become overloaded? How do you merge synonyms that have proliferated? How do you detect drift before it becomes debt?

These are not DDD questions. They are LDD questions.

A Story About a DDD Team That Learned LDD

I worked with a team that had been doing DDD for two years. They were good. They had Bounded Contexts. They had Aggregates. They had Ubiquitous Language documents. They had run Event Storming workshops. They were proud of their glossary. They also had Semantic Debt. They just did not know it.

The word Product meant one thing in the catalog context. Another thing in the pricing context. Another thing in the inventory context. The team had three Bounded Contexts. Three models. Three sets of rules.

But they still used the same word in every context. Product. The word sounded the same. It looked the same in code. It meant different things in different places.

The team thought they had solved the problem with Bounded Contexts. They had. The models were clean. The boundaries were clear. But the language was not. The word Product had become a false friend. A word that promised consistency and delivered confusion.

I asked them to rename the concept in each context. CatalogProduct. PricingProduct. InventoryProduct. Not in the code. Just in conversation. Just as an experiment.

They resisted. It felt redundant. It felt like extra typing. It felt like they were breaking the Ubiquitous Language.

Then they tried it for a week.

The difference was immediate. Meetings got shorter. Confusion dropped. People stopped asking “which Product do you mean?” because the name told them. The team realized that their Ubiquitous Language had been ambiguous without them noticing. The Bounded Contexts had hidden the ambiguity, not resolved it.

They kept the new names. They updated their code to match. Their language became more precise. Their system became easier to change.

That team did not stop doing DDD. They just added LDD on top. A little discipline around naming. A little attention to language. A little closure. A little ownership. It changed everything.

What LDD Takes From DDD

I want to be explicit about the debt LDD owes to DDD.

Ubiquitous Language is the starting point. Without that idea, LDD would not exist. LDD is, in some sense, an attempt to take Ubiquitous Language seriously enough that it actually works over time.

Bounded Contexts are the natural partner to Semantic Boundaries. LDD asks you to draw boundaries where the language splits. DDD asks you to draw boundaries where the model splits. These are the same boundaries if you are paying attention. If they are not the same, your language is lying to you.

Domain modeling is still essential. LDD does not replace modeling. LDD tells you to design the language before you model. But you still need to model. The modeling patterns in Part III of this book come directly from DDD, reframed through a linguistic lens.

Event Storming is still useful. Narrative Modeling, which is one of the core patterns of LDD, is a direct descendant of Event Storming. The difference is that Narrative Modeling starts with language first, then moves to events. Event Storming starts with events and discovers language along the way. Both work. Both have their place.

LDD is not a rejection of DDD. It is an appreciation of DDD that goes deeper. It takes the insights of DDD and asks the next question. The question about the language itself.

The Four Ideas DDD Does Not Have

Let me name five ideas that are central to LDD and absent from DDD.

Semantic Debt. DDD does not have a name for the cost of linguistic ambiguity. It talks about technical debt. It talks about model decay. It does not talk about the debt that lives in the gap between words and meanings. The debt that the fintech company paid every day.

Language Closure. DDD does not ask whether a language should be open or closed. It assumes growth is good. More words, more precision. That is not always true. Sometimes fewer words is more precise. The team with the thirty-page glossary learned this the hard way.

Design by Renaming. DDD treats renaming as a minor refactoring. LDD treats renaming as a primary design activity. Changing a name changes the architecture. It is not cosmetic. It is structural. The logistics company should have renamed Order into five concepts. They did not. They paid the price.

Wanderer Words. DDD models domains. It does not model the conversations between domains. It assumes that every concept belongs to a domain. Some concepts do not. They wander. The payroll company learned this. Their JournalEntry wandered between payroll and accounting. No one modeled it. The system suffered.

These are not minor differences. They are fundamental shifts in what you pay attention to. DDD looks at the model. LDD looks at the language that produces the model. Different focus. Different tools. Different questions.

A Different Metaphor

Let me try a metaphor.

DDD is like a master carpenter. The carpenter knows wood. Knows joints. Knows finishes. The carpenter builds beautiful furniture.

LDD is like a forester. The forester knows trees. Knows soil. Knows how wood grows. The forester does not build furniture. The forester makes sure the carpenter has good wood to work with.

You need both. A carpenter without a forester eventually runs out of good wood. A forester without a carpenter has a lot of trees and no furniture.

DDD is the carpenter. LDD is the forester. Different skills. Different tools. Same goal. Building things that last.

The fintech company had good carpenters. Their code was clean. Their models were elegant. Their carpenters ran out of wood. The language was rotten. The forester was missing.

LDD is the missing forester.

What This Means for You

If you are a DDD practitioner, you already have most of what you need. You understand that language matters. You have experience with Ubiquitous Language. You are ahead of most teams.

What you are missing is the discipline of language design. The practices for keeping language healthy over time. The patterns for refactoring language when it drifts. The awareness of Semantic Debt as a distinct kind of cost. The tools for closing your language. The ownership model for linguistic governance.

LDD adds that discipline. It does not ask you to stop doing DDD. It asks you to add a layer of attention beneath DDD. To care about the language itself, not just the model.

If you are not a DDD practitioner, that is fine too. You do not need to learn DDD to benefit from LDD. The patterns in this book work on their own. They do not require Aggregates or Bounded Contexts or Event Storming. They require attention to language. That is all.

But if you do know DDD, you will recognize the foundation. LDD stands on DDD’s shoulders. It looks in a different direction, but it stands on the same ground.

Closing Words

Let me end where I started.

Is this just DDD with a new name? No.

DDD discovered that language matters. LDD asks what it means to design language.

DDD uses language as a tool for modeling. LDD treats language as a design material.

DDD gives you Ubiquitous Language. LDD gives you the tools to keep that language ubiquitous over time.

They are different. They are complementary. They are not in competition. Here is what I want you to remember.

DDD taught us that software should speak the language of the domain. That was a gift. A gift that changed how we build software.

LDD asks a more uncomfortable question. What happens when the language itself starts lying? When the words stop meaning what they used to mean? When the Ubiquitous Language is no longer ubiquitous? When the Bounded Contexts hide ambiguity instead of resolving it? When the glossary becomes a fossil and the code becomes a museum?

Because the language will start lying. It always does. The only question is whether you will notice. And whether you will have the tools to fix it. DDD got us halfway there. LDD is the other half.