The domain model

Now that our development environment is in place, let's put together a domain model for our problem. A domain model describes the important concepts in the problem domain in a way that can be implemented in software. There are different techniques of preparing a domain model and there are different ways of representing a domain model. The most commonly used representation of a domain model is a class diagram. We will prepare a class diagram and define our classes and their attributes and relations on the basis of the knowledge that we have so far about our problem. I am going to take a slightly agile approach at this. What I mean by this is that I am not going to overly analyze anything here. We will prepare a very simple domain model that covers most of my requirements to a certain degree of comfort. As I go on implementing the features, I will uncover a lot of hidden domain knowledge, which will help me shape my domain model better.

Tip

Classes in a class diagram will have attributes, associations, and methods. At this stage, we are more interested in attributes and associations. This is because attributes and associations tell us what kind of data the class holds, while methods tell us what kind of operations the class supports. In order to persist a class in an appropriate database table, all you need to know is what kind of data the class holds. For this reason, I will concentrate on detailing the attributes and associations of the classes in our domain model.

Let's start building our class diagram. Let's start with a class representing an employee.

Employee

The Employee class represents an employee and should hold the following information at the very least:

• First name
• Last name
• E-mail address
• Date of birth
• Date of joining
• Address
• Password

Leave

The Leave class represents a leave benefit that the employees receive. The Leave class can hold the following information:

• Name
• Description
• Entitlement
• Remaining
• Type of leave (paid, sick, or unpaid)

SeasonTicketLoan

This is another employee benefit. This class can hold the following information:

• Name
• Description
• Amount
• Start date
• End date
• Monthly installment

SkillEnhancementAllowance

A skill enhancement allowance benefit. This class should have the following information:

• Name
• Description
• Entitlement
• Remaining entitlement

Next, we can start thinking about the relationships or associations between these classes. The following associations can be derived from the knowledge that we have:

• Every employee is entitled to a number of leaves of different types
• Every employee can avail the season ticket loan
• Every employee is eligible to get paid for skills enhancement training
• All three benefit classes have the name and description attributes, which can be moved into a common base class
• The address of an employee is not a primitive type and can be represented by a class
• Leave types (paid, unpaid, sick) can be represented by an enumeration

This mostly covers what we need to begin our journey. The following class diagram puts together all of the previous information:

If you look closely, I have added some attributes on the Address class to give it some shape. I have also added an attribute named IsAdmin to the Employee class. This attribute identifies an employee with admin rights.

One more thing that I have added is the association from the Benefit class back to the Employee class. This makes the association between the two classes a bidirectional one. An advantage of this bidirectional association is that for a given instance of the Benefit class, it is easy to find which employee this instance belongs to.