Pragmatic model driven development. Part III. Creating the domain model

Note. This series of posts is also published as a Capgemini group white paper and published in Software Release Magazine (in Dutch, in two parts).

The next step towards generated code, and other deliverables, is to create the domain model for the project. Next to the smart use cases, that capture the desired behavior, the domain model provides a structural view of the system.

Roughly said, the domain model captures the key concepts, types, rules, validations, and services of the business domain, expressed in customer terminology. Furthermore,  the model identifies the relationships between all major types.

In this pragmatic approach we follow and extend on the principles stated by Eric Evans in his domain driven design paradigm. As your might expect, the domain model is expressed in UML class diagrams. Primarily, the domain model models domain objects (or entities) such as Customer, Order, Subscription or Course and their relationships, expressed as associations. Next, the properties and their types are modeled.


We consider five different categories of property types, that are all applicable in different situations:

  • Basic types. In general, people tend to model property types in basic types, such as string, integer, boolean or date. However, we have more knowledge on most property types than that it’s just a string or integer. In this case it’s better to use value objects.
  • Value objects. A value object holds no identity, but reflects a value. In short, value objects are good for modeling property types that can be validated, such as Bsn, Isbn or Email.
  • Enumerations. We model property types as an enumeration, if the property can only have a limited, fixed number of different values. Think of ContractType, Gender or Level.
  • Smart references. Another pattern we apply to modeling property types, is the smart reference. We have agreed to model a property as smart reference if the property can only have a limited, but possibly changing number of different values. Here you could consider properties such as Department, Prefix or Country (if no other information on countries is required).
  • Associations. If a property has a type that itself is a domain object, we model an association. Note that in UML an association is actually defined as properties on both ends of the association.

Each of these categories of property types can be used nicely in code generation. For instance, enumerations and smart references can be used to fill drop down lists, and associations of course can be used to generate master-detail behavior or object-relationship mapping configuration files. Moreover, the multiplicity, role names and composite parts of associations can all be used in code generation.