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
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
See also http://martinfowler.com/eaaCatalog/domainModel.html
Is an EntityRelationshipDiagram
? 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
) 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?