Domain Model

A domain model can be seen as an interface or a pipe between the Requirement Engineering phase and the Design Phase of the software development life cycle.

http://www.site.uottawa.ca/~ssome/UCEdWeb/publis/domainGen.pdf

Rule of thumb: If you are passing around primitive data types among object collaborators, it may be an indication you are not communicating at the right level of abstraction. You need to see whether the primitive data types represent concepts in your domain that you may have missed. 

 http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

Let’s begin by using slightly different names. Let’s call the model of data that you persist the domain model and call the data you manage in the view the view model. I should mention that domain model isn’t exactly a neutral term in software, as it refers to an object model designed according to a number of additional rules. In the scope of this article, I’m not using the meaning that results from the Domain-Driven Design (DDD) methodology. For me, here, the domain model is simply the object model you persist—entity model might be another equivalent—and less confusing—term.

 http://msdn.microsoft.com/en-us/magazine/hh456393.aspx

I'll just add that at the heart of the application, there isn't necessarily *a* Domain Model, but possible *some* Domain Models.
The same application can have several aspects, or contexts, that might be modelled differently.
the cool stuff - all aspects might share the same storage mechanism (i.e. RDBMS tables), and it would fit perfectly in the Domain-driven Onion modelling of the system

 Ken Egozi - http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

GUI will ask Repository to get domain object by id.. and once GUI has the domain object you could navigate it to reach other objects.. This way Domain layer does not need to know anything about repositories..

 StackUnderflow - http://www.techques.com/question/1-458098/Business-Logic-Layer-and-Data-Access-layer:-circular-dependency see also on idea of splitting BLL into Service/Business Logic Layer and Domain Model Layer

• We'll have a richer domain model which contains state, relationships, and logic inherent to the objects in that domain model.
   http://stackoverflow.com/questions/4708689/ddd-where-to-put-persistence-logic-and-when-to-use-orm-mapping

The Domain Model is a self-contained component – it doesn’t take dependencies on anything else. What it does is raise events that external code can use to make decisions about which external “service” to call.

http://www.udidahan.com/2008/02/15/from-crud-to-domain-driven-fluency/

The definition fat model means having as many domain objects as needed. Be it reports, validators, filters, entities, strategies and so on.

http://www.thedeveloperday.com/skinny-controllers/