April 2, 2010 by huionn
When I kick start a new project in new domain, it is intuitive for me to draw a few domain models after getting initial requirements. It help me understand the key concepts and their relationship. However if I am asked what are those diagrams, I am speechless (I am not good in explaining…)
A domain model, or Domain Object Model (DOM) in problem solving and software engineering can be thought of as a conceptual model of a system which describes the various entities involved in that system and their relationships.
The domain model is created in order to document the key concepts, and the domain-vocabulary of the system being modeled. The model identifies the relationships among all major entities within the system, and usually identifies their important methods and attributes. The domain model provides a structural view of the system that can be complemented by other dynamic views in Use Case models.
An important benefit of a domain model is that it describes and constrains the system scope. The domain model can be effectively used to verify and validate the understanding of the problem domain among various stakeholders of the project group. It is especially helpful as a communication tool and a focusing point between technical and business teams.
Applying UML and Patterns, by Craig Larman
A domain model is the most important – and classic – model in OO analysis. It illustrates noteworthy concepts in a domain. It can act as a source of inspiration for designing some software objects…
A domain model is a visual representation of conceptual classes or real-situation objects in a domain. Domain models have also been called conceptual models, domain object models, and analysis object models.
The information domain model illustrates (using UML notation) could alternatively have been expressed in plain text (in the UP Glossary). But it’s easy to understand the terms and especially their relationships in a visual language, since our brains are good at understanding visual elements and line connections.
Therefore, the domain model is a visual dictionary of the noteworthy abstractions, domain vocabulary, and information content of the domain…
By using class names inspired from domain models, … this supports a low representational gap between our mental and software models.
Domain-Driven Design, by Eric Evans
A (domain) model is simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail.
Every software program relates to some activity or interest of its user. That subject area to which the user applies the program is the domain of the software…
To create software that is valuably involved in users’ activities, a development team must bring to bear a body of knowledge related to those activities. The breadth of knowledge required can be daunting. The volume and complexity of information can be overwhelming. Models are tools for grappling with this overload. A model is a selectively simplified and consciously structured form of knowledge. An appropriate model makes sense of information and focuses it on a problem.
A domain model is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge.
Patterns Of Enterprise Application Architecture, by Martin Fowler
An object model of the domain that incorporates both behavior and data…
- Generally, a domain model captures (physical) entities (user, item, etc), processes (sales, payment, reservation, etc), associations, information & records (history, catalog, receipt, etc), services (notification service, authentication service) and policies & rules.
- The visualization of domain model help designers and developers assign responsibilities to classes during implementation.
- There is no single correct domain model. An useful domain model is evolving to reflect deeper understanding in the domain.
- In my opinion, use case reflects the dynamic view of business processes, whereas domain model reflects the static view of OO implementation. By bridging between use case and domain model, the developed software will be more likely to fulfill user requirements.