📝Domain model

In software architecture, it is useful to describe a domain model. Domain model is what’s true about the domain regardless of your solution. (Solution is the subject of Design model.)

The following views/models can be used:

• Information model—describes what types exist and what their relationship is. Either textual or very simple diagram with 1-to-many relationships. Fairbanks₂₀₁₀ pp.131–133

  • Note that “types” here refer to real-world objects, not types in your programming language.

• Invariants (what’s always true, constraints) can be added to information model.

• Snapshot or instance diagram—a concrete instance of information model. Fairbanks₂₀₁₀ p. 134

• Functionality scenarios—describe how one snapshot transforms into another. (Similar to use cases.) Fairbanks₂₀₁₀ pp. 135–136

  • (If a step does not show a transformation in snapshot, consider if the step is necessary.)

  • Again, it is important to mention that these scenarios are about real world and not the system.

See also

• Design model

• For domain modeling, beware of adding technical details

Backlinks

• 📖 Just Enough Software Architecture
• 📝 § Software Modeling
• 📝 Multi-level functionality scenarios
• 📝 Design model
• 📝 For domain modeling, beware of adding technical details