Challenge: Coffee Shop Modeling Example

Domain Model

Try to create your version of the model, and then feel free to reveal the one below to compare them. Your data model may differ, and that’s ok.

Remember that, in our data, customers create orders and employees fulfill them.

Click to reveal a sample domain model

Sample Coffee Shop Order Domain Model

Is your data model different? If so, how (i.e. drawing style, different entities, properties/no properties)? What decisions or perspectives might have influenced the differences?

No matter what your model looks like, it’s important to note that there is no right or wrong way to draw it. For the next step, you could create either the database model or the application model. Since the database model is traditionally more restrictive, mapping to a database model seems a good next step.

Database Model

Feel free to choose whichever database modeling structure you are most comfortable with - relational, document, etc. You can create a generic model before looking at a graph version, using the human model you just created or the sample version above for your database model. Again, when you’re ready, reveal the one below to compare.

Click to reveal sample database model

Sample Coffee Shop Order Database Model

There is a lot more room for differences in this model. For example, did you create a generic Person entity where Customer and Employee are sub-entities? Can employees also create orders (i.e. purchase coffee for themselves)? Should there be a total property the Order entity? These are all valid questions that can lead to different database models.

Now here is a sample graph model.

Click to reveal sample graph model

Sample Coffee Shop Order Graph Model

Notice that the graph model is very similar to the human model. This is intentional because graphs are designed for the human domain model. Looking back at the relational model, there are a few extra fields built in for lookups. This might not be too terrible to explain to non-technical users, but more complex and diverse models increase the mismatch.

Graph models reduce the mismatch, improving understanding with small and large models. The graph model also translates well to the application domain model, which you will see in the next section.

Application Model

A sample Java application domain model might look like the one below. This is based off of the graph database model above.

@Node
class Order {
    @Id
    @GeneratedValue(UUIDStringGenerator.class)
    String transactionId;
    String orderNumber;
    LocalDate orderDate;
    LocalTime orderTime;

    @Relationship(value = "BOUGHT", direction = Relationship.Direction.INCOMING)
    Customer customer;
    @Relationship(value = "SOLD", direction = Relationship.Direction.INCOMING)
    Employee employee;

    // constructor, getters, and setters
}

@Node
class Customer {
    @Id
    @GeneratedValue(UUIDStringGenerator.class)
    String customerId;
    String customerName;
    String loyaltyId;

    // constructor, getters, and setters
}

@Node
class Employee {
    @Id
    @GeneratedValue(UUIDStringGenerator.class)
    String employeeId;
    String employeeName;
    LocalDate startDate;

    // constructor, getters, and setters
}

In the application model, there are three main entities - Order, Customer, and Employee. This looks very similar to the domain and graph models. The @Node annotation tells Spring that this entity should map to a node entity in the database. Similarly, an @Relationship annotation should map to a relationship entity in the database.

Application models tend to mirror database models closely because they need to retrieve data from the database. Typically, the more entities and relationships that are added to a model, the more the database model will deviate from the human model, impacting the application model, as well. Graph data models help to reduce this deviation, making it easier to maintain and understand the application.