Why Domain Knowledge Is a Defensible Line

Two People Look at the Same Screen and Read Different Things
Why Domain Knowledge Is a Defensible Line
Three Things a Business-Literate Engineer Does Differently
When the Words Diverge, So Does the Code
Six Steps for Learning a Domain
Where Domain Knowledge Does Not Carry
The Series in One Sentence
Try It This Week
Further Reading
Sources

Two People Look at the Same Screen and Read Different Things

A constructed illustration. Order cancellation carries one condition: once an order is in the shipped state, cancellation is unavailable and it becomes a return instead. Someone who only knows the code reads that as a state transition rule. Someone who knows the business knows that at the shipping moment a work order already went to the warehouse, that reversing it means a person there catching it by hand, and that the boundary of this rule was set by how many minutes that person has.

The difference between them barely shows when they change this feature. It shows when they judge whether the feature may be changed.

Part 1 named tacit context as the first thing that makes verification expensive, and domain knowledge is exactly that. Not in the code, usually not in the documents, held only in people's memory and organizational habit.

Translated into the Brooks distinction cited in part 3, domain rules are essential rather than accidental complexity. His own example was that if users want a program to do thirty different things, those thirty things come from the problem itself and cannot be removed. Changing tools does not shrink this side.

That said, "defensible line" should not be read as a moat that keeps others out. Domain knowledge has value not because it is scarce but because judgment is impossible without it. Giving it away does not reduce it — and putting it into a form that can be given away is half of this capability.

Three Things a Business-Literate Engineer Does Differently

First, the kind of question differs. The purely technical question is "what does this field mean?" The business-literate question is "are there real orders where this value is empty, and if so, in what case?" The second one surfaces the actual shape of the data.

Second, the posture toward exceptions differs. Faced with a strange exception clause in the requirements, the purely technical reaction is that it is messy and should be cleaned up. The business-literate reaction is to ask what accident that clause is the scar of. Clauses like that usually appeared after somebody lost money, and deleting them brings the loss back.

Third, they can tell what the real requirement is. Part 6 said requirements arrive dressed as solutions; unwinding that translation requires the domain. Without it, you can ask the question and still not understand the answer that comes back.

When the Words Diverge, So Does the Code

At the point where a domain becomes code, the thing that breaks most often is vocabulary.

The ubiquitous language Eric Evans proposed in domain-driven design addresses this. In Martin Fowler's summary it is the practice of building up a common, rigorous language between developers and users, and the reason it must be grounded in the domain model is that software does not cope well with ambiguity. The same page quotes Evans on the division of labor: domain experts should object to terms or structures that are awkward or inadequate for conveying domain understanding, and developers should watch for ambiguity or inconsistency that will trip up design.

The signal that this is failing is simple. When the word used in the meeting and the name in the code differ, a translation happens every single time, and every translation is an opportunity to mistranslate.

Example — a vocabulary comparison table

business word   name in the code                same thing?
settlement      settlement, payout, clearing    needs checking. why three?
shipped         shipped                         yes
return          return, refund                  no. goods and money move separately

The dangerous row is the first. When one word on the business side is split into three in the code and nobody holds the difference as a sentence, that is where a quietly wrong value comes out.

Six Steps for Learning a Domain

Collect the vocabulary. Gather nouns from meeting notes, screens, and customer emails without judging them.
Separate same from different. Merge different words that point at one thing; split one word that two departments use differently. The second is the most valuable find.
Split things from events. Sort each into a lasting object or something that happened at a moment. That split is the skeleton of the data model.
Attach cardinality. One to one, one to many, or many to many. This is where most misunderstandings come out.
Write validation questions. Take five questions the model should be able to answer if it is right, and ask a domain expert. If the answer stalls, the model is wrong.
Hunt exceptions. Repeatedly ask whether there are cases where this rule does not hold. A domain producing no exceptions has not been dug into yet.

The step most often skipped is the fifth. Everyone gets as far as drawing the model; few get as far as finding the questions the model cannot answer. In the language of part 4, drawing the model is generation and writing the validation questions is designing the judgment.

Where Domain Knowledge Does Not Carry

Three limits deserve an honest statement.

First, it does not transfer well. Ten years of logistics domain is largely discarded on the way to another industry. Investing only in the domain is therefore risky, and it has to travel alongside the transferable capabilities the previous nine parts covered.

Second, industries shrink. The deeper you are, the larger this risk gets, so where the industry is heading is as important a question as a technology choice when you pick a domain.

Third, there is overfitting. Stay in one industry long enough and its conventions start to feel like physical law. When "this is just how it is done" starts coming out of your own mouth, it is time to check. If you cannot put the reason into a sentence, it is not a reason, it is a habit.

The Series in One Sentence

Ten parts compress to this. The skills that hold value are the ones that stay expensive to verify, and an engineer's job is designing the machinery that turns expensive judgment into cheap judgment. Debugging, reading, testing, writing, framing, operating, delegating, learning, and domain were all faces of that one sentence.

That is also why the series never answered with a list of tools. Lists go stale; a discriminant goes stale more slowly. When the next tool arrives, there are two questions to ask. What does this make cheap? And therefore, what judgment stays expensive?

Try It This Week

Write down ten domain terms from your team and put the word the business side uses next to the name in the code. Thirty minutes. If even one row differs, that row is where the translation happens, and that is where a quietly wrong value comes out.

FDE Career RPG — its domain-analysis and ontology-building course drills exactly the six steps above. Across three fictional industries — manufacturing MES, logistics, and lending — you read stakeholder interviews, normalize the terms, assemble object types, properties, and link types with cardinality, and test the model with validation questions.
Collab RPG — a domain ultimately comes from people. It shows, on a delay, what the choice to ask and the conversation you postponed are worth weeks later.

Where this does not apply: on a several-week engagement, digging deep into the domain does not pay back. There the conclusion from part 3 holds — you need the boundaries, not the understanding.

Sources

Ubiquitous Language — Martin Fowler — the definition as building up a common, rigorous language between developers and users, the argument that it must be grounded in the domain model because software does not cope well with ambiguity, and the Evans quotation on what domain experts and developers should each watch for. Read 2026-08-15.
No Silver Bullet — Wikipedia summary — the point that essential complexity is caused by the problem to be solved and nothing can remove it, and the example that if users want thirty things those thirty things are essential. Read 2026-08-15.
The six-step procedure and the vocabulary comparison table are not from those sources; they are what this post assembles.

Two People Look at the Same Screen and Read Different Things