A key part of any development project is gaining a good understanding of the context, or domain, relevant to the
software or system being developed. Invariably the domain refers to the problem domain, which is understood as a
precursor to defining the solution domain. A description of the domain can take many forms. However, creating a model
of that domain aids understanding, helps stakeholders share a common view on the domain, provides the basis for scoping
the solution domain, and offers useful input to later analysis and design tasks.
Different people have different ideas about domain modeling, and the term "domain model" is heavily overused: It can
describe the various features of a specific domain, the commonality and variability of features in a domain, the
information being manipulated in a domain, and so on. Hence, this area can usefully be categorized into three main
A domain model is a model of the domain within which an organization conducts its business. Hence, in practice the
domain for one organization should be the same as that for any other organization conducting business in that domain.
In practice, however, variations in domain modeling are the result of two factors: the level of detail of the domain
model and how the model is used in the context of particular methodologies. At its simplest, the term domain model is
used to refer to the class diagram that is created to represent concepts in the domain and their primary relationships.
Typically, this will include classes with attributes and operations to represent conceptual domain elements. These
models may be annotated with informal information, supported by high level business use cases, and so on.
Domain modeling often includes understanding the existing software systems in use in a domain. In those instances, much
of the focus in domain modeling is to identify and model commonalities and differences that characterize the software
systems within the domain to provide an understanding of which aspects of the problem domain are currently addressed by
software. Domain modeling is used to define what the software systems are by systematically modeling the functions,
objects, data, and relationships of the software systems in the domain. This results in :
An understanding of the features of the software systems used in the domain.
A common vocabulary capturing the various stakeholders' understanding of the domain.
Complete documentation of software systems in use, their primary function, and relations.
A key output of domain modeling is an extensive domain dictionary that captures elements used in describing the
features and entities in the domain model, together with an overview of their primary purpose.
For more information, see also the Artifact: Business Analysis Model.
Domain analysis is "the process of identifying, collecting, organizing, and representing the relevant information in a
domain, based upon the study of existing systems and their development histories, knowledge captured from domain
experts, underlying theory, and emerging technology within a domain"[CMU/SEI-90-TR-21]
Domain Analysis should "carefully bound the domain being considered, consider commonalities and differences of the
systems in the domain, organize an understanding of the relationships between the various elements in the domain, and
represent this understanding in a useful way"[CARDS94].
Many different ways of analyzing the domain exist, depending on the form of the domain models being analyzed and the
different objectives for the analysis. For example, some techniques focus on analyzing similarities and differences in
product families. Feature Oriented Domain Analysis (FODA) is targeted at identifying distinctive user-visible features
within a class of related software systems. Other domain analysis techniques focus on particular viewpoints or concerns
within a domain. Cognitive Work and Safety Analysis (CWSA) focuses on the work that people do, the decisions they make,
and the strategies they use to support the identification of safety inadequacies in a system.
Domain engineering is an approach to enabling greater efficiency and reuse for realizing a family of similar systems.
Domain engineering covers all the tasks for building software core assets. These tasks include identifying one or more
domains, capturing the variation within a domain, constructing an adaptable design, and defining the mechanisms for
translating requirements into systems created from reusable components. The products (or software assets) of these
tasks are domain models, design models, domain-specific languages, code generators, and code components. This set of
tasks is fundamental to the creation of a systematic approach to reuse in an organization.
[CARDS94] CARDS: Nilson, Roslyn; Kogut, Paul; & Jackelen, George Component Provider's and Tool Developer's
Handbook Central Archive for Reusable Defense Software (CARDS). STARS Informal Technical Report
STARS-VC-B017/001/00. Unisys Corporation , March 1994.
[CMU/SEI-90-TR-21]Feasibility Study (CMU/SEI-90-TR-21, ADA 235785).
[EVANS03] E. Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003.
[FODA] Kang, Kyo C.; Cohen, Sholom G.; Hess, James A.; Novak, William E.; & Peterson, A. Spencer
Feature-Oriented Domain Analysis (FODA)
[SEI] Domain Engineering at the Software Engineering Institute: