Introduction

In part 1 of this series of posts, a health sampling area was described briefly from the business perspective. Following that, a domain model was defined with a set of initial rules in order to get a first version of such model. That version will be refined now with more detail about data and associations between entities of the subject domain.

Domain models capture the essence of the business where we are working on. It can be any domain. Given that we can abstract concepts and apply rules described in the first part of this series, it really can be any aspect of the real world.

Continuing modeling a domain

To recap, the creation of a domain model is structured in the following steps^[1]:

1. List all candidate conceptual classes or entities
2. Represent entities in a domain model
3. Add associations between conceptual classes
4. Add multiplicity
5. Add attributes

In the first part, the step 1 and 2 were carried out in order to generate a list of conceptual classes of the domain (aka entities) and represent them in a domain model. Now I’m going to finish the domain model adding all the required detail left.

3. Add associations between conceptual classes

Associations have the power to show how entities interact with each other. So no entity can be isolated without associations to other entities. That would be an anomaly in the model.

Figure 2.1 shows the domain entities with its associations:

4. Add multiplicity (and other details)

After adding associations to the model, it’s time to refine it with multiplicities and details like the name of the association and its direction. This adds meaning and expressivity to the model. Multiplicities express the instances that are related of the entities at some point of time.

Figure 2.2 shows the domain model with more detail:

5. Add attributes

The final step on the modeling is to add relevant attributes of the entities. This will provide with the data that is stored and manipulated in the domain model. These attributes are strictly from the business perspective.

Figure 2.3 shows the final model:

Conclusions of part 2

Refinement of the domain model happens in several steps and this has to be combined with iterations. Only this way the model will be expressive enough to have all the required details of the subject domain.

The objective of this series of posts is to produce a final physical model in a target database. But also there will be a bonus part with the conversion of this domain model to a design class diagram. In the next part will be generated the physical relational database model equivalent to this domain model.

Your comments are important so we can share knowledge, ideas and thoughts about domain model.

References

[1] Rational Software Corporation, Workflow Detail: Develop a Domain Model, 2001.