The intent of this blog is to describe the steps of creating a domain model for a new digital product. I will take the example of my latest project related to defining a domain model for the relaunch of the website of the Center for Contemporary Art "Rotor" from Graz.

Content is always about something and that something is a subject. A subject is a specialism or field of interest. While working on my user research for Rotor, I identified its subject domain, which would be exhibitions of contemporary art.

After researching the subject domain the next step was to define the domain model. The domain model is a structural model, so it is easy to mistake it for a site map. It is not a scheme for how the parts of our digital product are arranged. In the process of creating a domain model it is necessary to free our mind from thoughts of digital products altogether.

The domain model maps your subject, not your website. Atherton, M. & Hane, C.

One of the most important parts of the design process is to take apart our topic and see how it all works.

Within a domain model, each concept is called a domain object. In this initial phase it is important to carefully distinguish between domain objects and instances of those objects. The goal is to create a model that is reusable. An instance is a specific example of the concept represented by the domain object. The core activity of an art organization is to present art by organizing exhibitions. So I identified a domain object Artwork. A sculpture, graphic, painting or a photograph would be an example - or instance - of that object. Domain objects are general forms designed to cope with many instance examples.

Based on content concepts that I identified as important for representatives of Rotor’s target groups using the mental model method, I defined valuable domain objects for an art organization website.

The domain objects build a picture of the subject and each object represents a real-world concept. Objects names should be in singular because the model shows how one example of each object relates to one example of another object.

Expressing relationships in the domain model completes the picture of how one concept connects to another. Soon these relationships will inform the design of our content management system (CMS).

When we are done with defining domain objects, we need to put them somehow into relationships. If we understand domain objects as nouns, then relationships between those objects are the verbs that connect them. The structure would be:

Subject – Predicate – Object 

Domain models use the relationships between concepts to build understanding.

In the previous step I have used a simple connecting line to show a relationship between two domain objects. But now, to make a step forward, we need to express some ground rules about how things connect. In other words, we need to define how much of something can relate to something else. By establishing cardinality, we explain how the domain objects connect.

There are four main types of relationships:

●    One-to-one (1:1)

In a 1:1 relationship, one instance of one object relates to only one instance of another object. For instance, a specific Venue is located at a specific location. And the specific location is assigned to a specific Venue. In general, the practice says that true one-to-one relationships are rare. If we come across one, we should consider whether both concepts are true domain objects. It may be that one is merely an attribute of the other.

●    One-to-many (1:N)

In a 1:n relationship, an instance of an object can relate to several instances of another object. For instance, an exhibition consists of more artworks but they all belong to only one exhibition. One-to many relationships are the most common type we usually encounter.

●    Many-to-many (M:N)

In an m:n relationship, several instances of an object relate to several instances of another. For instance, several curators can work on several publications. But in this case, some issues can occur and our average relational database could have a meltdown. The practice states that in fact, true many-to-many relationships are rare. If we encounter an m:n relationship, it is possible that we have missed a domain object. It could be useful to review the relationship.

●    Optional relationships

An exhibition can have a partner organization but also does not need to have one. So, a domain object may have zero, one, or more than one instance of another domain object. In that specific case we can make a 1:1 or 1:n relationship optional by adding a circle to represent the zero.

When we are done with establishing relationships between all the domain objects, we have a model of our subject domain. Like any model, it is an abstraction from the specifics of reality. Our domain model will be a reference point for our team and help all parts involved from interface design and engineering, back-end engineering to content strategy to stay on the same path. In the next chapter I will present an art organization domain model and explain its structure.

The core activity of a contemporary art organization is to present art by organizing exhibitions. Thus, as defined before the subject domain of an art organization is contemporary art exhibitions.

In the domain model the exhibition gets the focus and around it all elements are arranged that add some information or stand in relation to it. The domain model of Rotor is shown in the next figure and the explanation of it is as follows:

An Exhibition (individual, group, performance, action…) has one or many Persons involved. The Person can have one or many Roles (curator, artist…). The Person works on one or more Publications and a Publication can have one or more authors working on it. Because of that, I introduced the Collaboration domain object.

One Person can be a part of one or more Collaborations. One Collaboration can work on one or more Publications. (The catch here is that now a person has to be associated with a book via collaboration, even when they are only collaborating with themselves. Maybe I should try to find a better word) my intention here was to resolve an m:n relationship into two 1:n relationships, and to facilitate the database design).

The Person (in the role of Artist) can be the author of one or more Artworks.

The Exhibition has one or more Artworks. An Exhibition has one Publication. Each Publication presents one or more Artworks. The Exhibition is hosted in one or more Exhibition space and each Exhibition space has one Location.

An Exhibition has one or more Related activities (workshop, lecture…) which are boundary objects that need a Domain Model for themselves. Each Exhibition has zero, one or more Partners with whom cooperation is established.

Source: Hane, C., & Atherton, M. (2017). Designing Connected Content: Plan and Model Digital Products for Today and Tomorrow (1st ed.). New Riders.