Streamlining User Availability Checks with Domain-Driven Queries and Repository Pattern

In the koder-animalts-web project, ensuring precise user availability for scheduling appointments is crucial. This is particularly true for distinct user roles like pet owners and veterinarians, where their schedules and booking rules can differ significantly. We recently implemented a robust user availability check system, leveraging domain-driven queries and the Repository Pattern to maintain clarity and flexibility.

The Challenge: Ensuring Accurate User Availability

Previously, handling availability checks directly within application services or controllers often led to convoluted logic. As the project grew, accommodating different rules for pet owners (e.g., restricted booking times, multiple pets) versus veterinarians (e.g., specific consultation hours, on-call shifts) could easily result in:

• Tight Coupling: Business logic for availability intertwined with data access specifics.
• Duplication: Similar availability checks re-implemented across different parts of the application.
• Difficulty in Testing: Complex dependencies making unit testing cumbersome.
• Scalability Issues: Hard to extend when new user types or availability rules emerged.

Our goal was to create a system where the rules governing 'availability' were clearly defined and isolated, irrespective of how that data was stored or retrieved.

Our Approach: Domain-Driven Queries and Repositories

To address these challenges, we embraced a Domain-Driven Design approach, specifically implementing availability checks through dedicated domain-driven queries and the Repository Pattern. This strategy promotes a clean separation of concerns, ensuring our domain models remain focused on business logic.

By defining clear owner and veterinarian modules, we encapsulate the specific logic and data access patterns for each user type. This means that an AvailabilityService doesn't need to know how to find a veterinarian's free slot, only that it can ask a VeterinarianAvailabilityRepository for it. This aligns perfectly with the principles of Hexagonal Architecture, where the core domain is isolated from external concerns like databases or UI.

Implementation Details: A Glimpse into the Code

At the heart of this system are interfaces that define what availability queries can be performed, without dictating how they are performed. Here’s a simplified TypeScript example:

// src/domain/interfaces/IAvailabilityRepository.ts
interface IAvailabilityRepository {
  isOwnerAvailable(ownerId: string, date: Date, timeSlot: string): Promise<boolean>;
  isVeterinarianAvailable(vetId: string, date: Date, timeSlot: string): Promise<boolean>;
}

// src/application/services/AvailabilityService.ts
class AvailabilityService {
  constructor(private availabilityRepo: IAvailabilityRepository) {}

  async checkCombinedAvailability(
    ownerId: string,
    vetId: string,
    date: Date,
    timeSlot: string
  ): Promise<boolean> {
    const ownerIsFree = await this.availabilityRepo.isOwnerAvailable(ownerId, date, timeSlot);
    const vetIsFree = await this.availabilityRepo.isVeterinarianAvailable(vetId, date, timeSlot);
    return ownerIsFree && vetIsFree;
  }
}

// Usage example (e.g., in a React component or API handler)
// const concreteRepo = new DatabaseAvailabilityRepository(); // Dependency Injection
// const service = new AvailabilityService(concreteRepo);
// const isSlotOpen = await service.checkCombinedAvailability(
//   "owner-abc-123", "vet-xyz-456", new Date(), "14:00");
// console.log(`Slot available: ${isSlotOpen}`);

This setup ensures that the AvailabilityService depends only on the IAvailabilityRepository interface, making it agnostic to the underlying data source (e.g., a database, an external calendar API, or even an in-memory mock for testing). The actual implementation of IAvailabilityRepository would reside within infrastructure layers, translating domain-level queries into specific data retrieval operations.

The Impact & Takeaway

By adopting domain-driven queries and the Repository Pattern, we've achieved a highly maintainable and testable availability system. Each module (owner, veterinarian) can evolve its availability logic independently, and the core application remains lean and focused. This architectural decision makes onboarding new developers smoother, as the clear boundaries clarify where domain logic resides.

Actionable Takeaway: For complex features involving varied data access rules or business logic, define clear repository interfaces and encapsulate domain-specific queries within dedicated modules. This isolates your domain, improves testability, and prepares your application for future growth and evolving requirements.

Generated with Gitvlg.com