Domain knowledge is understanding what a system's transactions mean to the business that runs it — settlement, claims, prior authorisation, inventory — and it is the thing that most often decides between two technically equal candidates.
High demand20 min readSolution Architect, Presales / Sales Engineer, Business Analyst, Product Manager, Enterprise Architect, Domain ConsultantUpdated 2026-07-27
Assumes you know: Enough delivery experience to read a system diagram and a data model, Comfort reading a specification or contract-style document end to end
Overview
What this area actually covers
Domain knowledge is knowing what the rows in the database mean to the business
that owns them: that a card authorisation is a promise rather than a movement
of money, that an insurance claim can be reopened years after it was closed,
that a retailer's most contended resource is a number representing stock it
cannot reliably count. Queues, indexes and idempotency keys are the same
everywhere; what differs is the meaning of each event and the cost of
misreading it.
Two things get wrongly bundled in. Requirements elicitation is a
business-analysis craft — running a workshop, writing an acceptance criterion —
whereas domain knowledge tells you which question was worth asking. Vendor
expertise in a core banking platform or a policy administration suite is
marketable but narrower, and it is often mistaken for fluency by people who
have only seen the domain through one product's screens.
Having worked at a bank is also not knowing banking. Engineers spend four years
inside a payments organisation building a notification service and never learn
what happens after authorisation.
This section is unusual on the site because it is about a capability rather
than an industry. It has three subsections, and they are sequential: how you
acquire understanding, how you speak it credibly, and how you turn it into
something a system can be built from. Each is a different failure mode, and
most people who struggle are strong at one and weak at another.
Acquiring Domain Knowledge is the deliberate method: which documents repay
reading, which questions extract what nobody wrote down, how to sequence your
learning so early ignorance does not embarrass you, and — the part almost
everyone skips — how to tell whether you have actually understood something or
merely acquired fluent phrasing about it. It exists as its own subsection
because the default approach, absorbing the business slowly by working in it,
takes years and produces uneven coverage. Open it for a repeatable acquisition
loop, the hierarchy of sources from primary to hearsay, and the tests that
distinguish understanding from vocabulary.
Speaking the Vocabulary is the social and practical problem of the terms
themselves. Stakeholders use domain words the way you use "cache" — without
definition, at speed, assuming shared ground — and the same word means
different things in two industries and sometimes in two departments of one
company. This is separate because it is a credibility mechanic rather than a
knowledge one: what damages you is not ignorance but repeated ignorance of the
same term, and there is a real skill in asking for a definition once, in a way
that reads as precision rather than as a gap. Read it for the terms that carry
the most weight, the ones that are false friends across domains, and how to ask
without paying for it.
Domain Modelling in Practice is the translation step: taking what the
business says and producing a model that survives contact with its exceptions.
It covers where the language of domain-driven design genuinely earns its keep —
a shared vocabulary, explicit boundaries between contexts that use a word
differently, a translation layer at the seam with a system you do not control —
and where invoking it is just vocabulary. It is separate because a person can
understand an industry completely and still produce a model that collapses the
first time a real exception arrives. Open it for how to find the exceptions
before they find you, and for what a model owes to the business that will
maintain it.
Subsection
What it is for
Acquiring Domain Knowledge
Learning an industry on purpose rather than by osmosis
Speaking the Vocabulary
Using the terms correctly, and asking without cost
Domain Modelling in Practice
Turning the business into a model its exceptions cannot break
Where it sits in a real business
Follow the money and the obligations and the domain becomes legible. A card
payment splits into three events: authorisation reserves a limit on the
cardholder's account, clearing exchanges details between acquirer and issuer,
and settlement moves real funds between banks, usually in a later netted batch.
Until then the merchant holds a receivable and the issuer a liability, and both
reconcile to prove their ledgers agree. Reconciliation, not throughput, is what
a payments engineer is judged on.
In insurance the product is a promise, so the hard problem is time: premium
arrives now against a loss reported years later, which is why insurers hold
reserves and why money can flow backwards through a settled claim. In retail
the constraint is physical, so the work is reservation and judging how much
overselling is cheaper than lost sales.
Now put the same-looking "order and payment service" in front of all three:
Constraint
Bank
Insurer
Retailer
Correctness
Reconciles to the cent, daily
Reserves defensible to an actuary
Eventual consistency, priced in
Load shape
Hard batch cut-offs
Decades-long records
Extreme promotional peaks
Deletion
Retention set by rule
Blocked while a claim could reopen
Routine
Latency
Authorisation, in milliseconds
Quoting only
Checkout, which converts
Failure costs
Licence and reporting risk
Mispriced risk, found years later
A lost basket
No row is a technology choice, yet every row changes the architecture. This is
why an architect who has only built retailers proposes an elegantly wrong
design for a bank.
Follow the counterparties, not the features
The fastest way into an unfamiliar industry is to stop asking what the software
does and start asking who the parties are, what each one wants, and what each
one can refuse. Almost every complication in an enterprise system is the
residue of a party who can say no.
Loading diagram…
The thing to look at is that money moves before the argument is resolved, in
the opposite direction to the original payment, and every arrow carries a
deadline. An engineer who has understood this diagram can reason about dispute
systems in domains they have never worked in, because the pattern — provisional
reversal, evidence, deadline, escalation — recurs in insurance recoveries,
healthcare claim appeals and marketplace seller disputes.
The same word, three meanings
The most reliable way to reveal that you are new is to use a term with its
meaning from another industry. These are the ones that catch people most often.
Word
In payments
In insurance
In retail or logistics
Settlement
Funds actually moving between institutions
Agreeing the amount to pay on a claim
Paying a seller their share
Claim
Rarely used; a dispute is a chargeback
A demand under the policy
A charge against a carrier for loss
Reserve
Funds held against a pending obligation
Money set aside for a known loss
Stock held for an in-flight order
Book
A portfolio of positions or accounts
The set of policies written
Not used
Exposure
Amount at risk with a counterparty
The unit that rating is applied to
Not used
Authorisation
A hold on a card, later captured
Approval to proceed with treatment
Permission to return goods
None of these is ambiguous inside its own industry. All of them are ambiguous
in a room containing two industries, which is precisely the room a solution
architect is usually in.
Which domains are worth knowing about
You cannot learn every industry, but you can hold a one-paragraph model of each
of the big ones, which is enough to follow a conversation and to know what you
would have to go and read. The paragraph that matters is not what the industry
sells; it is what its hardest constraint is, because that constraint explains
its architecture, its vocabulary and its regulator's attention.
Banking and payments is about moving value between organisations that
cannot coordinate. Its hardest constraint is that correctness is externally
audited and errors become somebody's missing money, so the domain is built on
immutable double-entry records, idempotent operations and daily reconciliation
against counterparties. Learn it if you want a domain where the definition of
correct is written down by someone else.
Insurance sells a promise whose cost is unknown at the point of sale. Its
hardest constraint is time: a contract can be amended retroactively, a claim
can reopen a decade later, and the system must be able to say both what was
true and what was believed on any past date. Learn it if bitemporal modelling
and configurable products interest you more than latency.
Healthcare separates the person receiving care, the person choosing it, the
organisation delivering it and the organisation paying. Its hardest constraint
follows from that separation: no single party owns the record, so identity is
probabilistic and interoperability is permanent. Learn it if you want a domain
where standards you did not write are the environment.
Retail and e-commerce promises goods it cannot perfectly count. Its hardest
constraint is that inventory is a claim about the physical world, so every
availability figure is a deliberate bet between overselling and lost sales.
Learn it for the fastest feedback loop of any domain here.
Logistics moves things that will not roll back. Its hardest constraint is
that physical and system state diverge by default, making reconciliation a
continuous process rather than an error path. Learn it if you want
distributed-systems reasoning forced on you by physics rather than by choice.
Domain
Hardest constraint
The question a newcomer should ask
Banking and payments
Externally audited correctness
What is final, and when
Insurance
Retroactive change over decades
What did we believe, and when
Healthcare
No party owns the whole record
Who is this record about
Retail and e-commerce
Stock cannot be counted reliably
What can we credibly promise
Logistics
Physical actions do not roll back
How fast do we detect divergence
The pattern across the rows is worth naming. In every one of these industries
the hardest problem is a gap between what the system records and what is true —
between authorisation and settlement, between belief and effect, between two
charts describing one person, between the shelf and the database, between the
scan and the pallet. Domain knowledge is largely the study of that gap in a
particular business, which is why it transfers better than it appears to.
Who does this work
The people who depend on it most specify systems rather than build them.
Solution architects choose between designs on commercial rather than technical
grounds. Presales engineers face a customer who tests within ten minutes
whether the vendor understands their business, and a demo using the wrong words
has already failed. Business analysts need enough of the domain to notice what
the expert left out. Product managers make prioritisation calls with regulatory
consequences.
A day is mostly reading — a consultation paper, a claims procedure, an
interface spec — then asking a business user to walk the exception path.
Builders can succeed with borrowed domain knowledge; the specify side cannot,
because it produces the model everyone else borrows.
Role
How they use it
What it costs them to lack it
Solution architect
Chooses between designs
A design that cannot be made compliant
Presales engineer
Establishes credibility fast
The deal, in the first meeting
Business analyst
Notices the unasked question
Requirements missing the exception path
Product manager
Prioritises against obligation
Shipping the wrong thing on a deadline
Enterprise architect
Sets standards across a landscape
Standards nobody in the business accepts
Senior engineer
Interprets a specification
Building precisely the wrong correct thing
The distinction worth internalising is between borrowing and owning. An
engineer can borrow domain knowledge from a good analyst indefinitely and do
excellent work. The moment your job is to produce the model that others borrow,
borrowing stops being available, and that transition is the one most people
find harder than the technical step up that accompanies it.
Demand, adoption and how that is changing
Regulated industries are mid-way through long, funded modernisation programmes
— core banking replacement, ISO 20022 migration in payments messaging,
healthcare interoperability around FHIR — and these fail on domain
misunderstanding far more often than on technology. Cost pressure has moved
regulated workloads onto cloud platforms, forcing every retention, residency
and audit rule to be re-expressed by someone who understands what it was for.
Meanwhile generalist engineers have become far easier to hire than people who
can talk credibly about one industry.
Be honest about the shape of that demand. Outside consulting, domain knowledge
is rarely hired alone; it is a multiplier on a delivery skill, which is why it
appears as an interview differentiator rather than a role title. Generic
explanation is now cheap — a model will describe a settlement cycle on request.
What stayed expensive is knowing which of four plausible readings applies to
this client, in this jurisdiction, given the exception their operations team has
handled manually for six years.
That last point deserves expanding, because it is the honest answer to
"is this worth learning now". Widely available explanation has genuinely
devalued the recall half of domain knowledge. Nobody is impressed that you can
define a chargeback. What it has not touched is the judgement half: knowing
which of the plausible answers this organisation actually operates, which of
its documented rules are dead letters, and which undocumented practice the
whole business quietly depends on. That knowledge exists only in people, and
extracting it is a skill.
What makes it hard
Vocabulary is the first barrier and it is brutally effective. A stakeholder
says "we're T+2 on the European book" or "that needs prior authorisation" and
moves on, because to them these are ordinary words. Settlement conventions show
why bluffing fails: US, Canadian and Mexican equity markets moved from T+2 to
T+1 in May 2024, while the UK and EU have announced a move for October 2027, so
the same phrase is current practice or history depending on the book. Prior
authorisation is a US health-payer control requiring treatment to be approved
before delivery, which turns a clinical workflow into a distributed transaction
with a party who can refuse. Nobody will explain either. Asking once is fine;
needing repeated explanation ends your credibility in the room.
There is a technique for the asking, and it is worth stating because people
avoid the question and then guess. Do not ask "what is X". Ask a question whose
answer contains the definition and which demonstrates you were following:
"when you say the European book is T+2, does that mean a trade today settles
Wednesday for that desk but Tuesday for the US one?" You get the definition,
you get the exception, and the room hears a question rather than a gap.
The exception path is the business
Any domain's happy path fits on a page and is already automated. The value sits
in reversals, disputes, partial payments, reopened claims and the customers
whose contract overrides the standard rule — none of it documented, because the
people who know it never had to write it down.
This is not a complaint about documentation; it is a structural fact about how
businesses accumulate. Standard behaviour gets automated and therefore written
down in code. Exceptional behaviour stays with the people who handle it,
because it is rare enough that automating it never reached the top of a
backlog. So the documented system is precisely the part that was easy, and the
undocumented part is the whole reason the operations team has headcount.
Loading diagram…
The loop to notice is the one back from the test in the middle. The exit
condition is not "I have read enough" but "I can predict what the operator will
say next", which is the only reliable signal that a mental model is doing work
rather than storing phrases.
Regulation is a design input
Residency rules fix deployment topology before you pick a region. Retention
obligations decide whether hard deletion is available to you at all, which
changes the data model. European strong customer authentication requirements
put an interactive challenge inside a flow you would otherwise have made
asynchronous. Treat any of this as a late review and you find in month nine
that the architecture cannot be made compliant, only replaced — and unlike a
code defect, being wrong surfaces as an audit finding long after the decision.
The useful discipline is to translate each obligation into a technical
constraint before design starts, and to write the translation down so it can be
challenged. "Personal data may not leave this jurisdiction" becomes a statement
about where a database, its backups, its logs and its support staff's screens
may be. "Records must be retained for the statutory period" becomes a statement
about whether your delete endpoint is a delete at all. Obligations expressed in
legal language and constraints expressed in architectural language are not
interchangeable, and the translation is where the errors live.
Turning it into a model
The last difficulty is that understanding does not automatically produce a good
model. The standard failure is a model built from the happy path, with the
exceptions bolted on as flags, so that a policy has an is_cancelled boolean
and nothing can express a cancellation that was later rescinded.
The most useful ideas from domain-driven design address exactly this. A
ubiquitous language means the model uses the business's words rather than
translated ones, so a conversation about the code is a conversation about the
business. A bounded context is an explicit acknowledgement that "customer"
means something different in servicing and in risk, and that pretending
otherwise produces one enormous shared object that serves neither. And an
anti-corruption layer is a translation boundary in front of a system whose
model you must consume but do not want to inherit, which is the normal
situation when integrating anything older than you are.
Loading diagram…
The node worth defending in a design review is the one labelled shared
identifiers. Two contexts that share identifiers can be reconciled; two
contexts that share a schema will eventually be one context with two owners and
no coherent model.
Where this language stops earning its keep is when it is invoked as vocabulary.
Announcing an aggregate root does not make a boundary correct, and a team that
has renamed its services without changing its couplings has bought nothing.
Why study it
The case is comparative. Two candidates give a similar architecture; one also
knows why the reconciliation window is what it is, and that is the one the
panel remembers. For anyone moving from building to specifying — engineer to
architect, analyst to product — domain fluency is usually the real blocker
rather than another framework.
It carries a cost people rarely mention until it has happened to them. Deep
expertise in one vertical narrows your market to that vertical and often one
geography, because much of what you know is jurisdictional. Eight years in US
healthcare revenue cycle or UK pensions administration makes you highly
employable inside a small pool and awkward outside it. Compensation tracks one
industry's cycle, and the knowledge decays when rules change. The protections
are a portable craft alongside the domain, or a second domain acquired early
enough that you own a method rather than one deep well.
The second domain is the underrated move. The first industry you learn takes
years and feels like memorisation. The second takes months, because you already
know the shape of the questions: who are the parties, what can each refuse,
where does money move against the direction of goods, which clock is binding,
what happens when it is reversed. Owning that method is more valuable than
owning either industry, and you only discover you have it by learning a second
one.
Skip it if you are interviewing for algorithm-heavy loops where the domain is
the product, or if you are early enough that fundamentals compound faster. This
is not the fastest route to a first senior title; it is the route to being
consulted before the design is chosen.
Knowing when you actually know it
The last difficulty is self-assessment, and it is the one people never build a
test for. Fluent phrasing arrives long before understanding, and it feels
identical from the inside, which is why an engineer who has read about a domain
for a fortnight can talk convincingly for ten minutes and then fail on the
eleventh.
Three tests separate the two states, and all of them are cheap. The first is
prediction: before an operator answers a question about an exception, write
down what you expect them to say. If you are consistently right, your model is
doing work. The second is the reverse direction: can you explain why the
business does something inconvenient — a delay, a manual step, a form that
asks twice — in terms of a constraint rather than in terms of legacy? Real
understanding usually reveals that the inconvenient thing is load-bearing. The
third is whether you can identify what would have to change for a rule to stop
applying, because a rule you can only state is memorised, and a rule whose
boundary you can find is understood.
Your first hour
Deliberate acquisition beats a decade of osmosis, and the method is to work
from primary artefacts. Pick one business event — a card refund, a motor claim,
a hospital discharge — and find a real public document about it: a regulator's
consultation paper, a message definition, an insurer's policy wording. Read it
once without looking anything up, then trace that event on one page:
Event: cardholder disputes a completed transaction
Parties cardholder, merchant, acquirer, scheme, issuer
Money merchant debited provisionally; final movement only
once the dispute closes
Records dispute case, evidence bundle, ledgers on both sides
Clocks scheme deadlines; missing one loses the dispute
regardless of merit
Rules evidence retention; limits on card data in the file
Exceptions refund already issued; merchant no longer trading;
second presentment
The template generalises, which is the point of it. Swap the event for a motor
claim and the parties become insured, broker, adjuster, repairer and reinsurer;
the clocks become notification deadlines and limitation periods; the exceptions
become a claim reopened after settlement and a policy endorsed after the loss.
Six rows, filled honestly, will orient you in any industry on this site.
Fill the exceptions row last and make it the longest. Then define fifteen terms
from the document in your own words, each with one sentence on what breaks if
you misread it. You end with a brief you could hand an engineer, and its gaps
are your reading list.
The step that converts this from an exercise into a habit is the last one:
find someone who does the job and get them to correct your page. Fifteen
minutes with an operations analyst will produce more correction than a further
day of reading, because they will immediately point at the row you got
plausibly wrong. Plausibly wrong is the dangerous state, and it is invisible
from the inside.
What this is not
It is not compliance: compliance evidences that rules were followed, while
domain knowledge lets you design something that satisfies them by construction.
It is not vendor training, and a certification in one platform's configuration
language is not transferable understanding. It is not requirements elicitation
either, though business analysts need both.
Nor is it a substitute for technical judgement — the failure mode of
long-tenured specialists who know the business precisely and propose designs
that will not survive load. And it is not seniority: twelve years in one
industry yields domain knowledge only if you spent them asking why, and
otherwise yields familiarity with one company's workarounds.
Finally, it is not a set of facts to be memorised before an interview. What a
panel is testing is whether you can reason about an unfamiliar business
correctly, which is why the strongest answer to a domain question is often a
question: which party can refuse this, and what happens to the money while
they think about it.
The vocabulary is a gate and nobody will hold it open for you — the terms get
used in front of you exactly once, and your credibility depends on already
knowing them.