I read about domain model and its importance and I have the following doubts :
What kind of problems can one resolve with domain models? in other words,for each problem I should build a domain model?
As far as I know, The domain models are represented using class diagrams .there is no difference between class diagram and domain model?
I also would like to understand In which way is vocabulary related to a domain model?
Pretty much any problem that you want/need to provide a software solution for is amenable to modelling. In fact: however you do it, you must 'model' your problem domain in some way, shape or form. If you don't capture the rules and policies of the problem in software somehow it's pretty unlikely the end system will meet its intended requirements.
It depends what you mean by 'build a domain model'. See above and below...
Class Diagrams are one way to model a domain. Actually, they're one way to model part of a domain. The primary advantage of a Class Diagram is that it exposes the relationships in the problem space explicitly and clearly. There is a body of opinion that says the semantics of a domain arise primarily through the relationships among concepts (classes) - more so than the classes themselves. If you buy into that opinion then it's possible/likely that you'll find a class diagram useful.
Note however that Class Diagrams only capture the structural elements of a domain: Classes, Attributes and Relationships. A CD doesn't capture behaviour. A Domain Model needs both structure and behaviour if it's to model the problem space in any useful way. So you'll need to augment the class diagram with some behavioural description; e.g. state models and/or actions.
There are other ways to model domains too. It can be a set of java/c# classes. The main disadvantage of such an approach is the reduced emphasis on relations. Unlike class diagrams, OO languages don't provide relations as first class constructs. The advantage is that programming language environments (editors/compilers/libraries/language runtimes) provide much better support for defining the behavioural aspects of a domain than most modelling tools.
More generally there's no rule that says a Domain Model has to follow the OO paradigm. It could be a set of functions and types in Haskell or OCAML. Or it could be some differential equations or other mathematical construct.
The key thing is that the model - however expressed - provides a description of the problem space. To be useful that description will not be complete - it will only capture the subset of properties in the problem space relevant to the system requirements. To be useful however it should be correct - the concepts and behaviour that are captured should accurately reflect the world being modelled.
You can think of a Domain Model as a way to produce a formalised and highly structured vocabulary. Actually, it captures some grammar too; e.g. it says that the participants in the 'Ownership' Relation must be a Dog and a Person; not two Dogs, or a Person and a Spoon.
This is what Eric Evans calls 'Ubiquitous Language' in Domain Driven Design. It means that the terminology used in the model should accurately reflect that of the problem being modelled. So if the real world domain experts use the words 'Person' and 'Dog', the model shouldn't use 'Homo Sapien' and 'Canine'. The rationale is simple: if developers (modellers) use the same terms as the domain experts, there's much less chance of misinterpretation. It also leads to more productive and pleasant conversations since everyone is using familiar words with a common meaning.
Summary
hth.