The diagram below (Figure 1) shows an excerpt from a domain model early on in the example project. As the project progresses, you'll allocate behavior (methods/operations) and data (fields/members) to each domain object, until it becomes an entity class, part of the overall design.

Figure 1: Drill down: example of a domain model diagram

Top 10 domain modeling guidelines

Each chapter's top 10 to-do list contains a concentrated dose of what you need to know, with the chapter delving into more detail and providing examples and exercises that illustrate each point. Here's our domain modeling top 10 list – pay attention, I'll be asking questions later:

10. Focus on real-world (problem domain) objects
9. Use generalization (is-a) and aggregation (has-a) relationships to show how the objects relate to each other
8. Limit your initial domain modeling efforts to a couple of hours
7. Organize your classes around key abstractions in the problem domain
6. Don't mistake your domain model for a data model
5. Don't confuse an object (which represents a single instance) with a database table (which contains a collection of things)
4. Use the domain model as a project glossary
3. Do your initial domain model before you write your use cases, to avoid name ambiguity
2. Don't expect your final class diagrams to precisely match your domain model, but there should be some resemblance between them
1. Don't put screens and other GUI-specific classes on your domain model

Domain modeling in practice

Our next diagram (Figure 2) shows a domain model diagram with attributes on the Order class. Take a close look at this diagram - what problem does it suggest?

Hint: this relates back to item number six in the chapter's opening domain modeling top-10 list.

Figure 2. Class diagram showing attributes

Domain modeling – the answer: Mapping database tables to domain classes

The Order domain class includes attributes that really don't seem like they belong in an Order class (see Figure 3). The most likely cause is that the modeler has mapped these domain classes directly from a relational database schema. Figure 4 gives the corrected diagram. The extra attributes have been separated out into their own domain classes (customer account and dispatch).

Note that we'd generally not show the attributes at all during domain modeling.

Figure 3. Order class domain attributes erroneously influenced from database schema

Figure 4. Domain attributes this time in more appropriate classes

Conclusion

In this excerpt we described the first major stage of the ICONIX Process. Domain modeling forms the basis for the whole object modeling activity. The key point here is that you start out with an initial, rough attempt at the domain model before writing the use cases, then refine the domain model (discover new objects, add attributes and operations) as you work your way towards detailed design, tests, and code.

In their next installment Matt and Doug will look at use cases, which are written in the context of the domain model. The next two pieces will examine robustness analysis (preliminary design), which helps tighten up both the domain model and the use case text, bringing the use cases and object model closer together.

Use Case Driven Object Modeling with UML: Theory and Practice is available for purchase through Register Books, at the special price of £34.99.