Domain Model

A DomainModel is an object model of a problem domain. Elements of a domain model are DomainObject classes, and the relationships between them.

A similar definition is given in TimHoward's book TheSmalltalkDevelopersGuideToVisualWorks: "use the term domain model to describe all the domain object types and the relationships among their instances, which collectively describe the domain space."

For many years domain models were the major concern of object methodologists. The succession of books on object-oriented analysis that appeared in the late 1980s and early 1990s were focussed exclusively on domain modeling, and at least one of those authors (PeterCoad) still has that primary narrow focus. However as IvarJacobson et.al. describe in ObjectOrientedSoftwareEngineering, the domain model is only one of (at least) three areas in which analysis is needed to specify a system.

What are the two other cases, besides domain model?? And does it mean oo applications built in the late 1980s were flawed since they did not benefit from the other two areas that were important? --dl

Jacobson et. al. say that the "requirements model" of a system consists of the domain model, the use case model, and the user interface model. Chances are there were flawless OO applications built in the late 1980s for which a use case model and user interface model were never really analyzed and specified, as well as highly flawed OO applications for which those models were analyzed and specified in the utmost detail. --RandyStafford

SuccessByChance? doesn't seem like a strong case for those other two areas. Perhaps their importance is within their role in teamwork?

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

Is an EntityRelationshipDiagram a DomainModel? All of the above discussion seems to put the DomainModel in the implementation phase of a project, whereas, judging from the contexts in which I've seen the term used, I thought it to be an abstract part of the DesignPhase. Like, you sit down with the CEO and figure out the problem he wants solved. This gives you your domain model that is composed of entities that interact in specific ways. Am I totally off base?

To me it seems that an EntityRelationshipDiagram is a DomainModel, with the domain being the information that is processed by the system. A system may for example process info about clients, products, contracts, addresses, and so on. These can be represented by an EntityRelationshipDiagram. --FrankScholten

Perhaps this is related: SchemaDesignIsModeling.

Frank, you are not off base. The example you described appears to be a domain model. EntityRelationshipDiagram is a notation that is often used to specify DM, but is not limited to DM.

I agree with comment of CraigLarman on domain model being overloaded (see 3 posts before). I also would like to add that notion of problem (and solution) domain is not absolute, but relative. Therefore it is possible to have a DM for a particular solution space in which software objects are designed/implemented, as well as another DM for software "domain layer". -- Andriy Levytskyy

How much the DomainModel (in the sense suggested by Fowler) is actually successfull in EnterpriseApplication when there is a need for persistence? Fowler in PEAA suggested a pattern where the DomainModel is backed by a ObjectRelationalMapper (or DataMapper) such as HiberNate ?

I was told experiences where this model that Fowler defends has failed in practice because of the overhead (memory foot print) of the ObjectRelationalMapping layer and difficulty to get the DomainModel right by most teams. Anybody has references/background on this? How much of this problem was solved with progress of ObjectRelationalMapping tools in 2009?

Do most people just dropped the object-oriented modeling in favor of a more procedural design such as Core J2EE Patterns at http://redirect.corp.yahoo.com/?url=http%3A%2F%2Fjava.sun.com%2Fblueprints%2Fcorej2eepatterns%2FPatterns%2Findex.html with a Business Delegate, Session Facade, Data Access Object and Data Transfer Object which maps in Fowler's vocabulary to TransactionScript, and a POJO ORM-managed table data gateway?

--GuillaumeBerche?

CategoryAddress CategoryModeling