Domain modeling

From Knowledge Kitchen
Jump to: navigation, search


Domain analysis starts early in the development process to create a common understanding between the client and the developers of the scope and major entities that exist in a system.

A domain model, also known as a conceptual model, is (unsurprisingly) a conceptual model of the system, created by identifying the most important 'things' or entities present in the system. Such diagrams help teams develop a common understanding of the application problem space and the domain within which the system is working.

Domain models are conversational in nature and do not attempt to represent an exhaustive specification of the system. While they do not display anything directly related to how the system should be written in code, they can be useful as a starting point for thinking about the classes and objects necessary.

Whereas use cases and user stories help understand the users and their interactions with the system, domain modeling helps understand the internals of the system to be built.

Living document

Domain analysis and modeling may continue to evolve throughout the project as the team learns more about the project.

  • Working on the project gives you a different understanding of the domain.
  • New features change your understanding of the domain
  • When user stories are refined, during Backlog Grooming, more details may come out about the domain
  • an up-to-date domain model can help maintain a common understanding between the development team and Product Owners

Use in Agile methodologies

In Agile development processes, which favor implementation over documentation, system specification documents such as domain models are created on an as-needed basis, and are created and updated whenever that is useful, often at the start of a project and on an as-needed basis during Sprint planning.

Identifying domain entities

Identifying entities in a domain model. Diagram by Dr. Michael Eichberg of Technische Universität Darmstadt

Identifying the entities in a conceptual model of a system typically can be done within a few hours by following a straightforward process:

  1. go through all existing documentation of the system, including any product vision statement, requirements, user stories, use cases, and underline or write down all the nouns
  2. remove redundancy from this list of nouns - things that are represented by different words that represent the same thing can be consolidated and the vocabulary standardized
  3. identify any nouns that might be attributes or properties of other nouns
    • If any attribute is not roughly equivalent to either a number or some text in the real world, then it is probably a conceptual class, not an attribute and should be its own entity.
  4. identify any associations between nouns

Create a diagram of these entities

Example of a domain model diagram, indicating important entities, attributes, relationships, and multiplicity. Diagram by Dr. Michael Eichberg of Technische Universität Darmstadt
A slightly simpler domain model diagram that does not include attributes. Image from Programming Foundations: Object-Oriented Design on

After identifying the entities in the system, develop a simple diagram that represents these entities, including any important or interesting relationships among them.

  • These diagram follow the UML conceptual class diagramming notation
  • use rectangles around each noun
  • write attribute names inside the rectangles, if useful
  • draw lines connecting nouns that have interesting relationships between them
  • write verbs that describe these relationships
    • avoid generic verbs, like 'has', 'contains', or 'uses'
  • indicate multiplicity of the entities in a relationship, if known
    • multiplicity includes an upper and a lower bound indicating the number of each entity involved in the relationship

Note that domain modeling is similar but distinct from Entity Relationship Diagramming (ERD), which is used in relational database design. The two serve separate purposes.

Determining each class's responsibilities

In addition to identifying the conceptual entities and their relationships, it is also sometimes useful to determine what responsibilities each entity has. These can be added as additional notes to the domain model diagram.

Similar to how we analyze our specification for nouns in order to discover the entities, we analyze the specification for verbs to help identify the responsibilities, or behaviors, of each entity. This will ultimately be useful when thinking of our entities in terms of object types and their responsibilities as methods.




What links here