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.
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.
The Employee
class represents an employee and should hold the following information at the very least:
The Leave
class represents a leave benefit that the employees receive. The Leave
class can hold the following information:
This is another employee benefit. This class can hold the following information:
A skill enhancement allowance benefit. This class should have the following information:
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:
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.