Domain Model
Important Decisions :
- Generalization of Technician, Customer, and Administrative Assistant into User class :
We wanted to avoid the repetition of fields in our domain model. Since all of the possible users need to have a first name, last name, phone number, and id, we created an abstract User class. However, later on, in order to reduce the number of classes we have, we decided to use Account class instead of user. Nonetheless, we decided it is better for us to use the abstract User class.
- No owner class :
At first multiple drafts of our domain model had an owner class in it. It was a subclass of users as technicians, Customer, and Administrative Assistants. We ended up deciding not to have an owner class since it has no functionality.
- TimeSlot class :
We created a separate class for time slots because if the time slot is an attribute in the Appointment class it would be more difficult to do later in the coding.
- Service type enumeration :
On the first draft of our domain model, we created an enumeration class for the service types. However, later on we decided to keep the serviceType as a string so that if later on, the shop decides to add on more service types.
- Composition between User and Account:
We made a composition association between the User class and Account class because each account belongs to a specific user. If we delete one user from the system, the account related to that user a
