Domain Overview

A fundamental step in any object oriented programming project is to define the objects, or domain, that we’ll be working with.

In this case we only have the project brief to work from, but it happens to include everything we need.

Analyzing the Brief for the Domain

A simple, but incredibly effective way to identify the domain is to go through the available documentation and identify the nouns – the things. They then become our objects and their instance variables.

If we look at the brief we see two words popping up a lot, and that’s “Task” and “Task List”, where the relationship between Task List and Task is “contains” – that’s to say that a Task List contains Tasks.

If we dig a little further we can see that a Task List should have a name or a title – some way of identifying it, and it can have an optional description as well.

A task also has a title and a description, but it also has a due date – the date and time the task should be completed by.

A task should also be able to be complete, so it would make sense for the Task object to have some kind of status associated with it.

Finally, there’s talk of a task having a priority, which I assume to be high, medium, and low.

Domain Model Diagram

With this information identified, we now need some way of capturing it, so let’s create a Domain Model Diagram, which captures the core concepts and relationships between them.

In this diagram you can see I’ve captured the TaskList and Task objects, their “contains” relationship, and the instance variables that we identified from our analysis.

What’s new here is that I’ve decided to represent a task’s status and priority as enums, which are TaskStatus having the values of OPEN and CLOSED, and the TaskPriority HIGH, MEDIUM and LOW.

I’ve shown the relationship between Task to TaskStatus, and Task to TaskPriority as having a “has” relationship. That’s to say that a Task has a status and a Task has a priority.

This is a great evolution from picking out some words on a page, but it’s missing some information, such as types, and the additional instance variables we would need to make a working system.

So let’s evolve this further into a Class Diagram.

Class Diagram

This diagram shows the classes we are to implement for our domain. You can see it includes additional instance variables such as id, created and updated, which are needed to identify our objects and give us admin information, such as when it was created and last updated.

We can also see that all instance variables have a type associated with them. I’ve elected to use UUIDs for ids rather than use an ascending numeric sequence in the database – both would work, but UUIDs tend to be easier to scale.

I’ve also included the instance variables which implement the relationships between our classes, for example you can see priority and status instance variables in the Task class.

If you’ve been taught the Domain Driven Design approach, you might be wondering why I’ve chosen not to model each class’s methods in this diagram. Perhaps our Task class should have a close method to move it from open to closed status?

It should be noted that each class will have getter and setter methods, and they are omitted from this diagram as they would simply clutter it up and perhaps confuse matters. However, as is typical in a Spring Framework application, we will not place our business logic into our domain classes, but instead into service classes, but more on those later.

Entity Relationship Diagram

Finally, for completeness, let’s include an Entity Relationship Diagram. This diagram shows how our domain, or “entities”, are organized and related in a relational database.

We can see a potential database table implementation, along with the many-to-one relationship between Task and TaskList. A TaskList will have many Tasks, a Task will belong to one TaskList.

Although we could implement this in a nosql database, given the clear relationship, we will use a relational database for this project.

Now that we understand the domain we will be working with, let’s explore what the user interface of such an application might look like.

Summary

• The domain consists of two main objects: Task and TaskList with a "contains" relationship
• Task's have a many-to-one relationship with TaskLists
• The domain will be implemented using a relational database business logic will be placed in service classes rather than domain objects