Domain & Industry Knowledge
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.
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.
Where to go next
Now practise it
6 interview questions in Working in a Domain, each with the rubric the interviewer is scoring against.
- A stakeholder keeps using a term you have never heard. What do you do in the meeting?
- How do you turn what the business tells you into a domain model that holds up once the exceptions arrive?
- Everyone in the business calls it the fax queue, and nothing has been faxed since 2014. Do you keep that name in the code?
- The domain expert tells you one thing and the written procedure says another. How do you work out which one the system should follow?