| Scope | Phases | Roles | Activities | Abstraction/Refinement Level |
|---|---|---|---|---|
From system to components to classes |
Analysis, design |
Domain expert, designer |
Object-oriented analysis and design, tactic DDD |
multiple |
An analysis-level domain model captures domain concepts and their relations from an external, non-technical point of view. A design-level domain model represents design solutions for the concepts in the analysis model (including logic/behavior and data/structure).
A domain model shows the essential (most important, core) concepts an application deals with, and how these concepts relate to each other. Such a domain model helps domain experts (a.k.a. business analysts), architects, developers, and all other project stakeholders to establish a common understanding of the business problem at hand, which is an important milestone en route to an appropriate software design. Examples of such domains are business sectors such as finance, insurance, and telecommunications as well as somewhat more technical genres such as online shopping, Internet of Things (IoT), and social networks.
In the context of stepwise API and service design, a domain model is instrumental to identify candidate endpoints for the provider-side service layer.
Depending on the maturity of the design and the phase/stage of the project, domain models can be very minimal and only feature business concepts as classes and relationships. More elaborate domain models might include behavior in the form of method names or even complete method signatures and data attributes, domain events, and business rules (constraints, invariants).
Domain models are usually created early in the project and are refined continuously throughout the project. They complement and glue requirements specifications and architectural models.
Martin Fowler distinguishes between simple domain models, that "look very much like the database design" and rich domain models, which use "inheritance, strategies, and other @Gamma:1995 patterns, and complex webs of small interconnected objects" (@Fowler:2002). UML class diagrams are the most commonly used notation for domain models.
Note: A domain model does not have to specify every detail of the resulting implementation, but should show the most important concepts and give the reader an understanding of the code.
A minimal domain model can start with just the classes and their relations. For example, here is a very simple domain model for an e-commerce site:
The classes can then be logically grouped and fleshed out with more details, for example with more specific relations, attributes, and methods:
Note the filled diamond composition between order and line items, which form a part-of relationship. In a next step, the method names could be turned into full method signatures with fully typed parameter names and return values.
Pen and paper or a whiteboard are enough to get started on a simple model. The examples above were generated using PlantUML, a textual DSL for various kinds of diagrams. UML profiles exist as well and are supported in UML tools such as Sparx Enterprise Architect.
Context Mapper, a DSL and tool for strategic and tactic DDD, embeds Sculptor. The Sculptor DSL can express domain models.
Rapid prototyping tools, such as JHipster, can turn a domain model into fully functional applications. JHipster uses its own JDL modelling language to express domain models.
- A Domain Model is not a data-centric Entity-Relationship Diagram, even if these two artifacts might look very similar at the first glance. For instance, a domain model does not contain any notion of primary keys, whereas the typical ER diagram does not use inheritance. Domain models are supposed to feature attributes and operations. Martin Fowler warns about such Anemic Domain Models.
- A Domain Model may serve as an early check to see whether the desired functionality can be implemented, for instance by making sure that all required relationships are present.
- The refinement of the Domain Model should not be forgotten as more use cases or user stories are implemented and the design evolves (but often is). A model, diagram, or document that is not up to date may cause unnecessary confusion, for instance when the cardinalities (multiplicities) of relationship advance from 1:1 to 1:n and then n:m over time.
Note: While often associated with object oriented languages, domain modeling can also be used in functional programming languages. See Debasish Ghosh's book "Functional and Reactive Domain Modeling".
When UML-based methods and their predecessors are applied, chances are that a domain model is present:
- "UML Components" by John Cheesman and John Daniels has a business type model artifact (which is an early OOA domain model).
- Craig Larman's book "Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development" (@Larman:2004) covers OOA and OOD. Note that the "Domain Model" is the OOA artifact, while the OOD output is captured in an atifact called "Design Model".
- Tactic DDD can be seen as domain modeling "on steroids".
- ER diagrams from Structured Analysis (SA) can be used alternatively.
- Informal glossaries of the project's ubiquitous language can feed the domain model or be extracted from it (Context Mapper provides a Freemarker template for this purpose, for instance).
- Code-level class diagrams might use the same notation, but have a different purpose.
Several books were listed under "Origins and Signs of Use" above. Cesare Pautasso discusses the different kinds of models -- domains models among them -- used to capture an architecture in @Pautasso:2020.
An end-to-end design demo that includes some OOAD and Tactic DDD is described in this Medium story.
title: "Design Practice Repository (DPR): Domain Model"
author: Mirko Stocker (STX), Olaf Zimmermann (ZIO)
date: "03, 30, 2021"
copyright: Olaf Zimmermann, 2020-2021 (unless noted otherwise). All rights reserved.
license: Creative Commons Attribution 4.0 International License