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.
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.
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:
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