Domain-Driven Design

Started reading Domain Driven Design. Will try to write about my thoughts on the book and the subject as I proceed.

The key point thus far is that the domain very much represents a common language that will be used to communicate ideas, requirements, and behaviors (both of the system and the business) between developers and domain experts. At the same time it must be comprise a functional piece of a software system. This dual role will help keep the requirements of the users and the design of the software in sync. The model should not in any way be concealed from the domain experts (and users). It should be used as the language of communication. When either side finds it difficult to communicate aspects of the software or of the business using only the lexicon of the model, it is quite likely that the model is not "right", in that it either does not properly "map" to reality, is overly complicated or focused on technical (software) details, or is incomplete.

Accept that that the model will never be perfect, but must evolve continually evolve as everyone (developers and domain experts) works towards the development of the software. It is important to remember that even the domain experts, while knowing the business side very well, may not know how to formulate their understanding into a formal (and executable) model.
The model does not need to model everything known about the business, only what is pertinent to the current goals of the software system. It is a model of some reality, after all, and not a duplication of reality.