Anatomy of a Domain Model
The following document outlines the anatomy of a domain model created with TinyModeler. For illustration purposes, we'll be using the Creature/Skill model shown below.
The boxes in the model are known as Entities. They represent a type of data that needs to be represented in the domain. These Entities typically map to tables in databases and classes in object-oriented programming languages. For this model, there are four Entities: Create, Skill, Acheivement, and Proficiency.
Each Entity has a set of Properties (or Attributes). They are single pieces of information that can be stored with each instance of the Entity. Each Property as a name and data type (shown next to the name after a colon). For example, the Creature Entity has two Properties: name and type, both with data type string. These Properties are stored as columns in a database.
Besides the data type, each Property has a value called nullability. Its possible values are:
- nullable: value can be null
- not null: value cannot be null (dashed underline)
- identity: value forms part of the entity's identity (solid underline)
The first two simply indicate whether or not a value of the Property needs to be present in the Entity instance. The last one is used to define the Entity's identity, discussed in a later section.
Mapping to Tables
Although each Entity only shows up once in the model, it represents many rows in a database table (or objects in an object-oriented programming langauge). If we were to map the Creatures Entity to a database table with a couple rows, it might look something like this:
Although the id column is not explicitly listed as a Property in the Entity, it is often included in the database as a primary key. This is left as a choice during implementation of the design.
The lines connecting Entities are known as Relationships. A Relationship is the combination of two Links, one for each Entity involved. A Relationship represents a connection between two Entities that allow them to access information about each other. Links with a bar near their Entity means that the Link is a part of the Entity's identity, discussed below.
Each Link has an associated arity. This defines how many instances of the Entity are allowed on that side of the Relationship. The possible value are 'one' and 'many'. When the arity is set to 'many', the Link will be drawn with prongs (like chicken feet). When one Link has an arity of 'one' and the other has an arity of 'many', it's a one-to-many Relationship. This is most common type of Relationship, as can be seen in the model above.
The one-to-many Relationship between Creature and Acheivement might be read as: For each Creature there are many Acheivements, or For each Acheivement there is only one Creature.
Mapping to Tables
When implementing Relationships in a database, it's common to store arity 'one' Links in an Entity's table as a column that hold the other Entity's id. For example, consider a possible database implementation of the Acheivement Entity:
In this example, Creature 1 is linked to Skill 4, and so on.
An Entity's identity is the collection of values that can be used to uniquely identify any instance from the others. Often it's only one value, like a simple numeric identifier. However, it's useful for some Entities to have a more complex identity. The definition of each Entity's identity can have a dramatic impact on the domain model.
For example, consider the Acheivement Entity above. It's identified by the Creature and Skill Entities that it's linked to. This means that each pair of Creates and Skills can only be lnked together once. If, however, we added a Property called date and made it a part of Acheivement's identity, we could link a Creature and Skill together one time for each value of date.