DCI supports human mental models. These include end user mental models and programmer mental models.

If you can think of an internal Use Case, for example in a banking system, transactions and audit logs, then DCI can handle it. That is one set of mental models, one Context. It is likely at a lower level than a bank account user.

Speaking of different models, it's important not to replace an end user mental model with transactions, databases, or the locus of storage of passwords. There has been many experiments of eliciting the end user mental model of a financial transfer; most of the current DCI implementations reflect that elicited model. The model initially underwent some of the discipline of grounded theory development and has more recently been “textured” (the last step in grounded theory) by more informal dialogue. The model is sound in light of research — though it is probably not sound in the eyes of a nerd trying to force a computer science world model onto it.

Another explanation by Cope:

End users are people with mental models. So are programmers. Trygve has said time and again that the programmer mental model is also important. So are those of marketing and sales, of the architects, of the domain analysts. Good design is hard because you have to synthesise many mental models into one piece of code. DCI is about slicing the mental models along the natural lines of change.