#domainmodel

The term domain model is overloaded, meaning different things to different communities. In information modeling and also in the Unified Process, it means the same as an "analysis object model" or a "conceptual model" (terms from Fowler and Odell, respectively). This use of DM meant a description of domain concepts in the domain of interest (e.g., some "real world" like stock trading), visualized in a box-and-line notation. Fowler's "Analysis Patterns" book, my "Applying UML and Patterns: Intro to OOA/D" book, Coleman's "Fusion Method" book and many more used the term in that way. This kind of DM is _not_ a picture of software objects, or of the software "domain layer" in an app. The other most common meaning, arising mostly out of the Smalltalk community (e.g., MVC), is that DM means the domain layer of software objects. That is, software objects with names like "Stock" and "Trade" and with method behaviors related to those domains. This layer usually has very low coupling to other layers in the architecture, but high internal cohesion. I've seen numerous misunderstandings in web postings and questions when the parties were using the terms in different ways, without knowing that others meant something alternate. --CraigLarman