Business Rules - Diyar68/Slotify GitHub Wiki

Business Rules

This page defines the business rules and domain constraints of the Booking System.

Business rules describe conditions that must always be respected by the application, independently of the user interface or API implementation.

1. Provider

BR-P01 – Provider Name

A Provider must have a name.

BR-P02 – Provider Email

A Provider must have a valid email address.

BR-P03 – Unique Provider Email

A Provider's email address must be unique.

Two Provider accounts cannot use the same email address.

BR-P04 – Provider Password

A Provider must have a password.

The password must never be stored as plain text.

BR-P05 – Unique Booking Slug

Each Provider must have a unique bookingSlug.

The bookingSlug is used to identify the Provider through their public booking page.

Example:

/book/friseur-ali

Two Providers cannot use the same booking slug.

2. ServiceOffering

BR-S01 – Service Name

A Service must have a name.

BR-S02 – Service Duration

A Service must have a duration greater than zero.

Examples:

  • Haircut → 30 minutes
  • Beard Trim → 15 minutes
  • Hair + Beard → 45 minutes

BR-S03 – Service Ownership

A Service belongs to exactly one Provider.

A Provider can offer multiple Services.

BR-S04 – Service Management

Only the Provider who owns a Service may manage that Service.

This includes modifying or removing/deactivating the Service.

3. Availability

BR-AV01 – Weekday Required

An Availability must define a weekday.

Example:

MONDAY

BR-AV02 – Valid Time Range

The start time of an Availability must be earlier than its end time.

Valid:

09:00 – 17:00

Invalid:

17:00 – 09:00

Invalid:

09:00 – 09:00

BR-AV03 – Availability Ownership

An Availability belongs to exactly one Provider.

A Provider can define multiple Availability periods.

BR-AV04 – No Overlapping Availability

Availability periods of the same Provider on the same weekday must not overlap.

Invalid example:

MONDAY 09:00 – 15:00

MONDAY 13:00 – 18:00

These periods overlap.

Multiple separate periods on the same weekday are allowed.

Valid example:

MONDAY 09:00 – 12:00

MONDAY 13:00 – 17:00

This can be used to represent breaks.

BR-AV05 – Recurring Weekly Availability

Availability represents the Provider's recurring weekly schedule.

Example:

MONDAY 09:00 – 17:00

means that the Provider is normally available every Monday during this period.

Date-specific exceptions such as holidays, vacation, or modified working hours are not part of V1.

4. Appointment

BR-A01 – Future Appointment

A new Appointment must not be created for a time in the past.

BR-A02 – Appointment Within Availability

An Appointment must fit completely inside one of the Provider's Availability periods.

Example:

Provider Availability:

09:00 – 17:00

Service duration:

45 minutes

Requested start:

16:30

Calculated Appointment:

16:30 – 17:15

The Appointment is invalid because it ends outside the Provider's Availability.

BR-A03 – No Appointment Overlap

A new Appointment must not overlap an existing blocking Appointment.

Example:

Existing Appointment:

10:00 – 10:30

Requested Appointment:

09:45 – 10:30

The requested Appointment is invalid because the periods overlap.

BR-A04 – Appointment Service

An Appointment belongs to exactly one Service.

The Service determines which Provider the Appointment belongs to.

Therefore, the Appointment does not require a separate Provider relationship in V1.

BR-A05 – Appointment End Time

The Appointment's endTime is calculated by the system.

The Customer only selects the desired startTime.

The calculation is:

endTime = startTime + service.duration

The Customer cannot define the Appointment duration or end time.

BR-A06 – Customer Information

A booking requires the following Customer information:

  • Name
  • Email address
  • Phone number

The Customer does not have a separate account or Customer entity in V1.

The contact information is stored as part of the Appointment.

BR-A07 – Start Time Required

Every Appointment must have a start time.

BR-A08 – Initial Appointment Status

Every newly created Appointment automatically receives the status:

BOOKED

BR-A09 – Customer Cannot Set Status

The Customer cannot select or modify the Appointment status.

Appointment status changes are controlled by the system and the Provider.

BR-A10 – Completed Appointment

A past BOOKED Appointment may be marked as:

COMPLETED

by the Provider when the appointment was successfully completed.

The system must not automatically mark an Appointment as COMPLETED simply because its time has passed.

BR-A11 – No-Show

A past BOOKED Appointment may be marked as:

NO_SHOW

by the Provider when the Customer did not attend the Appointment.

BR-A12 – Provider Cancellation

A BOOKED Appointment may be cancelled by the Provider who owns the corresponding Service.

The Appointment status changes to:

CANCELLED

Customer cancellation is not supported in V1.

BR-A13 – Cancellation Does Not Delete Appointment

Cancelling an Appointment does not delete it.

The Appointment remains stored with status:

CANCELLED

This preserves the Appointment history.

BR-A14 – Cancelled Appointments Do Not Block Time

An Appointment with status CANCELLED does not block its time period for future bookings.

The time can therefore become available for another Customer.

5. Booking

BR-B01 – Dynamic Time Slot Calculation

Available booking times are calculated dynamically.

Time slots are not stored as separate entities in V1.

The calculation is based on:

  • Provider Availability
  • Selected Service duration
  • Existing blocking Appointments

BR-B02 – Service Determines Slot Duration

Available booking times depend on the duration of the selected Service.

For example, the available times for a 15-minute Service may differ from those of a 45-minute Service.

BR-B03 – Booking Must Be Revalidated

Availability must be validated again when the Customer confirms the booking.

Displaying a time as available does not guarantee that it is still available when the booking is submitted.

This prevents stale availability information from creating conflicting Appointments.

Example:

  1. Customer A sees 10:30 as available.
  2. Customer B also sees 10:30 as available.
  3. Customer A books 10:30.
  4. Customer B attempts to confirm 10:30.
  5. The system checks availability again.
  6. Customer B's booking is rejected.

BR-B04 – Provider Determined Through Service

The selected Service must belong to the Provider whose booking page the Customer is using.

A Customer cannot create an Appointment using a Service belonging to another Provider.

6. Appointment Status Lifecycle

V1 supports the following Appointment statuses:

  • BOOKED
  • COMPLETED
  • CANCELLED
  • NO_SHOW

The allowed lifecycle is:

BOOKED → COMPLETED

BOOKED → CANCELLED

BOOKED → NO_SHOW

A newly created Appointment always starts as BOOKED.

Terminal statuses are not changed further in V1.

7. V1 Limitations

The following rules and concepts are intentionally not handled in V1:

  • Date-specific availability exceptions
  • Holidays and vacation periods
  • Customer accounts
  • Customer booking history
  • Customer cancellation
  • Appointment rescheduling
  • Multiple employees per Provider
  • Multiple locations
  • Online payments
  • Calendar synchronization
  • Email confirmations and reminders

These features can introduce additional business rules in later versions.