Domain & Industry Knowledge

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.

The three areas underneath

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.

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:

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.

sequenceDiagram
    participant CH as Cardholder
    participant M as Merchant
    participant A as Acquirer
    participant S as Scheme
    participant I as Issuer
    CH->>I: Disputes the transaction
    I->>S: Raises a chargeback
    S->>A: Debits the acquirer
    A->>M: Debits the merchant and asks for evidence
    M-->>A: Evidence bundle
    A->>S: Represents the transaction
    S->>I: Passes the evidence on
    I-->>S: Accepts or escalates

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.

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.

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.

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.

flowchart TD
    A[Pick one business event] --> B[Read a primary source about it]
    B --> C[Trace parties, money, records, clocks]
    C --> D[Ask an operator to walk the exception]
    D --> E{Can you predict the next answer}
    E -->|No| C
    E -->|Yes| F[Write the one page brief]
    F --> G[Have the operator correct it]

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.

flowchart TD
    A[Business language] --> B[Bounded context, servicing]
    A --> C[Bounded context, risk]
    B --> D[Shared identifiers only]
    C --> D
    D --> E[Anti corruption layer]
    E --> F[Legacy core system]

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.