Domain model
 | This article needs additional citations for verification. (November 2015) |
In software engineering, a domain model is a conceptual model of the domain that incorporates both behavior and data.[1][2] In ontology engineering, a domain model is a formal representation of a knowledge domain with concepts, roles, datatypes, individuals, and rules, typically grounded in a description logic.
Overview
[edit]In the field of computer science a conceptual model aims to express the meaning of terms and concepts used by domain experts to discuss the problem, and to find the correct relationships between different concepts. The conceptual model is explicitly chosen to be independent of design or implementation concerns, for example, concurrency or data storage. Conceptual modeling in computer science should not be confused with other modeling disciplines within the broader field of conceptual models such as data modelling, logical modelling and physical modelling.
The conceptual model attempts to clarify the meaning of various, usually ambiguous terms, and ensure that confusion caused by different interpretations of the terms and concepts cannot occur. Such differing interpretations could easily cause confusion amongst stakeholders, especially those responsible for designing and implementing a solution, where the conceptual model provides a key artifact of business understanding and clarity. Once the domain concepts have been modeled, the model becomes a stable basis for subsequent development of applications in the domain. The concepts of the conceptual model can be mapped into physical design or implementation constructs using either manual or automated code generation approaches. The realization of conceptual models of many domains can be combined to a coherent platform.
A conceptual model can be described using various notations, such as UML, ORM or OMT for object modelling, ITE, or IDEF1X for Entity Relationship Modelling. In UML notation, the conceptual model is often described with a class diagram in which classes represent concepts, associations represent relationships between concepts and role types of an association represent role types taken by instances of the modelled concepts in various situations. In ER notation, the conceptual model is described with an ER Diagram in which entities represent concepts, cardinality and optionality represent relationships between concepts. Regardless of the notation used, it is important not to compromise the richness and clarity of the business meaning depicted in the conceptual model by expressing it directly in a form influenced by design or implementation concerns.
This is often used for defining different processes in a particular company or institute.
A domain model is a system of abstractions that describes selected aspects of a sphere of knowledge, influence or activity (a domain[3]). The model can then be used to solve problems related to that domain. The domain model is a representation of meaningful real-world concepts pertinent to the domain that need to be modeled in software. The concepts include the data involved in the business and rules the business uses in relation to that data. A domain model leverages natural language of the domain.
A domain model generally uses the vocabulary of the domain, thus allowing a representation of the model to be communicated to non-technical stakeholders. It should not refer to any technical implementations such as databases or software components that are being designed.
Usage
[edit]A domain model is generally implemented as an object model within a layer that uses a lower-level layer for persistence and "publishes" an API to a higher-level layer to gain access to the data and behavior of the model.
In the Unified Modeling Language (UML), a class diagram is used to represent the domain model.
See also
[edit]- Domain-driven design (DDD)
- Domain layer
- Information model
- Feature-driven development
- Logical data model
- Mental model
- OntoUML
References
[edit]- ^ Fowler, Martin. Patterns of Enterprise Application Architecture. Addison Wesley, 2003, p. 116.
- ^ Fowler, Martin. "P of EAA - Domain Model"
- ^ Evans, Eric Domain-Driven Design: Definitions and Pattern Summaries. Domain Language Inc., 2006, p. 3.
Further reading
[edit]- Halpin T, Morgan T: Information Modeling and Relational Databases, Morgan Kaufmann, 2008. ISBN 978-0-12-373568-3.
- Fowler, Martin: Analysis Patterns, Reusable object models, Addison-Wesley Longman, 1997. ISBN 0-201-89542-0.
- Stewart Robinson, Roger Brooks, Kathy Kotiadis, and Durk-Jouke Van Der Zee (Eds.): Conceptual Modeling for Discrete-Event Simulation, 2010. ISBN 978-1-4398-1037-8
- David W. Embley, Bernhard Thalheim (Eds.): Handbook of Conceptual Modeling, 2011. ISBN 978-3-642-15864-3.