A domain model is the most importantand classicmodel in OO
analysis .[1] It illustrates noteworthy concepts in a domain. It can act as a source of inspiration for designing some software objects and will be an input to several artifacts explored in the case studies. This chapter also shows the value of OOA/D knowledge over UML notation; the basic notation is trivial, but there are subtle modeling guidelines for a useful modelexpertise can take weeks or months. This chapter explores basic skills in creating domain models.
more advanced domain modeling p. 507[1] Use cases are an important requirements analysis artifact, but are not
object -oriented. They emphasize an activity view.
As with all things in an agile modeling and UP spirit, a domain model is optional. UP artifact influence emphasizing a domain model is shown in Figure 9.1.
Bounded by the use case scenarios under development for the current iteration, the domain model can be evolved to show related noteworthy concepts. The related use case concepts and insight of experts will be input to its creation. The model can in turn influence operation contracts, a glossary, and the Design Model, especially the software objects in the
domain layer of the Design Model.
domain layer p. 136
![[View full size image]](/image/library/english/13744_09inf01_alt.gif;380137){kind=link}