A domain model is the language, behavior and tools we use to solve problems in a particular field.
An application consists of many different levels of domain models.
At the top level, for example, the domain model might be a business model - consisting of customers, invoices and a general ledger. At the next level the domain model might be a database, consisting of records and tables and queries. The next domain model might be file access consisting of device control, files, and buffers.
In an ideal world we would program each of these levels with a language and IDE that is specific, or at least optimized, for that domain. The next best solution is to have a library specific to the domain that we can use from a general purpose language.
In reality, however, that isn't always the case. In some cases we end up using the wrong domain model for a solution. For example we might program a business application in terms of rows and tables. Or we might not use a database and instead write the data straight to files.
This ends up with unnecessarily complex and unreliable code: The further away our code is from the appropriate domain model, the more complex the code is. Complex code means more testing, more maintenance and impedes our ability to enhance and extend the code. Applications suffer because of complexity.
On the other hand, code that is very close to the domain model is easier to read, especially by those familiar with the domain. It is usually more succinct, and is less prone to errors because of its clarity. You're also more likely to get it right the first time because the language of the requirements, if written, will be far easier to translate into code. For example, if the requirement is to collect a list of all the files on your hard drive, the simple DOS (incidentally a domain specific language for managing files) command "dir c:\ /s" can't really go far wrong.
So when you are developing an application, you should look at the domain of the problem you are trying to solve and make sure you are writing code specifically to that domain.
First see if there are any domain specific languages that could be leveraged to code it up. For example, if the domain relates to database management, look at SQL or perhaps XPath/XQuery. If the domain is text manipulation, look at RegEx or Perl. If the domain relates to GUI elements, look at HTML or WPF. Or for business work flow, you could use a workflow flow-chart designer.
Failing a DSL, look for a domain specific library that you can use from your general purpose language. This will consist of a number of functions or classes that represent the different abstractions in the domain. For example a class for a customer record, or WPF for creating GUIs, or WWF for creating workflows. The goal is to have your code written in terms familiar to the domain appropriate to the problem you are solving.
Failing a domain specific library, you can proceed to code up the domain model yourself. General purpose languages like C# or Java are pretty good at creating abstractions, and this can be used to create domain models. Heck there's even a design pattern for creating a domain model using an object oriented GPL. If you're particularly ambitious you could even try creating your own domain specific language using something like JetBrains' MPS.
What's important is that you're coding in a language that is appropriate for the domain, otherwise you'll likely end up with some messy, unmaintainable, unreadable and unreliable code.