I simply love this quote of Rumi. When you reduce internal noise, ego, assumptions, urgency, and the need to respond or control, your capacity to truly perceive increases.

In domain modelling, listening is not a soft skill. It is the core technique. The quality of a model depends less on notation and tooling, and more on our ability to hear where the domain hurts.

Too often, domain modelling begins with structure. Processes, Entities, attributes and relationships. We arrive with patterns already in mind and a quiet hope that reality will conform. We ask questions, but we listen selectively, steering conversations toward the shapes we already recognise.

When that happens, pain points get filtered out. Friction sounds like inconvenience. Workarounds sound like edge cases. Inconsistencies get labelled as data quality issues instead of signals of deeper misalignment in process, ownership, or incentives.

Quiet domain modelling starts with restraint. With letting practitioners describe their work in their own language, at their own pace, without correcting terminology or collapsing nuance too early. When we quiet ourselves, people stop reporting what they think the system wants to hear and start describing what actually makes their work difficult.

Pain shows up indirectly. In pauses. In repeated explanations. In stories that begin with “what usually happens is” or “we technically should, but”. These are not modelling noise. They are modelling signals.

Elicitation questions that surface pain

The goal of elicitation is not to ask clever questions, but to ask questions that create space for discomfort, ambiguity, and lived experience.

Some examples:

• “Can you walk me through the last time this went wrong?”
• “Where do you spend the most time fixing or rechecking things?”
• “What do you have to explain repeatedly to others?”
• “What information do you not trust, even if the system says it is correct?”
• “Where do exceptions pile up?”
• “What do you do manually that you wish you did not have to?”
• “Who gets involved when something breaks, and who should be involved but is not?”
• “What are you careful not to touch because it might cause problems elsewhere?”
• “What is technically possible but practically avoided?”
• “If you could remove one step from this process, which one would it be, and why?”

Notice that none of these ask for solutions. They ask for experience. They invite stories, not answers. They allow pain to emerge without naming it directly.

When we listen this way, domain models change. They become less idealised and more honest. Less optimised for systems and more aligned with reality. Boundaries sharpen. Concepts gain weight. Ownership becomes visible.

Domain modelling, then, is not just an act of abstraction and Elicitation.
It is an act of attention.