Domains: Domain independent vs. Dependent knowledge?

The Master (Dr Who's arch enemy, The Dominus?)

Domain

An area of territory owned or controlled by a particular ruler or government.

‘the French domains of the Plantagenets’

Origin

Late Middle English (denoting heritable or landed property): from French domaine, alteration (by association with Latin dominus ‘lord’) of Old French demeine ‘belonging to a lord’ (see demesne). (OED)

I rather like the idea of being a Dominus! (Lord) But I was probably born in the wrong century.  Actually maybe being an "Emperor" is better (ruler of all the Lords?)

I was recently asked about my experience in different "domains" which naturally got me wondering what a domain is, what domains I have experienced, and what is domain independent vs. dependent knowledge?


Wikipedia says:

Knowledge which may be applicable across a number of domains is called domain-independent knowledge, for example logics and mathematics. Operations on domain knowledge are performed by meta-knowledge. Domain Knowledge is the knowledge of a particular stream.

From this perspective I've always assumed I work at the "meta-knowledge" level - I have knowledge about knowledge. You don't see many job descriptions looking for "meta-knowledge" skills!

What are some possible domain variables? Private vs public vs government organisation, external or internal users/clients, subject matter area, size (?), geographical reach, type of "data" and "applications" (e.g. text, images, sensors, historical, real-time, structured/unstructured), etc. Could get complicated.   I'll start by simply trying to enumerate who I've worked for and the domains were.
Here's the high level summary, I've aggregated similar domains (e.g. financial related), and rounded durations up to 1 year min (most projects would have been 12 weeks min duration, most longer).
Note that ISR = Intelligence Surveillance and Reconnaissance, Space, Electronic Warfare, and Cyber Security

How do domains impact ICT knowledge and requirements? A trivial example is that until I first started working with "enterprise middleware" (J2EE) I hadn't really taken note of the fact that some distributed systems need to be Transactional.  In Banking and finance this is a very common requirement, but not in any application domain or technology stack I'd encountered up until them. Sure, some had the idea of success and failure, but there were different mechanisms for detecting and correcting problems.

Another example that comes to mind is real-time systems. For example stream event processing. Minimising latency and maximising concurrency is the goal. You can't afford to be waiting for shared resources, polling to get events, and you need sufficient worker threads to ensure nothing is left waiting in a queue for long. Monitoring is also critical to ensure the system is working fast enough. For event stream systems the computational processing is therefore typically triggered by each new event coming into the system (e.g. on a queue). For "real" real-time systems you actually need to be able to guarantee that the physical resources required are available all the time (dedicated hardware, and capacity planing to ensure that nothing gets saturated, and sufficient redundancy if one or more resources fails).