Scheduling Bounded Context

Relevant source files

The following files were used as context for generating this wiki page:

• Core/Scheduling/Scheduling.Domain/Patients/Patient.cs
• Core/Scheduling/Scheduling.Application/Patients/Commands/CreatePatientCommand.cs
• WebApplications/Scheduling.WebApi/Controllers/PatientsController.cs
• Core/Scheduling/Scheduling.Infrastructure/Persistence/Configurations/PatientConfiguration.cs
• Core/Scheduling/Scheduling.Infrastructure/Persistence/Migrations/SchedulingDbContextModelSnapshot.cs
• WebApplications/Scheduling.WebApi/Program.cs
• claude.md

The Scheduling Bounded Context is a core module of the DDD learning project focused on healthcare appointment scheduling. Its primary responsibility is managing the lifecycle of the Patient aggregate and facilitating appointment-related domain logic. It follows Domain-Driven Design (DDD) tactical patterns, including the use of Aggregates, Entities, Domain Events, and a clear separation between Domain, Application, and Infrastructure layers.

Sources: claude.md:20-24, Core/Scheduling/Scheduling.Domain/Patients/Patient.cs

Domain Model: Patient Aggregate

The central entity of this context is the Patient aggregate root. It encapsulates patient identity and status, ensuring that business rules are maintained throughout state transitions.

Patient Lifecycle and States

A patient exists in one of several states defined by the PatientStatus SmartEnum: Active, Suspended, or Deleted. State transitions are protected within the aggregate to prevent illegal movements (e.g., suspending an already suspended patient).

The state machine above illustrates the valid transitions for a Patient entity within the domain.
Sources: Core/Scheduling/Scheduling.Domain/Patients/Patient.cs:51-87, Core/Scheduling/Scheduling.Infrastructure/Persistence/Configurations/PatientConfiguration.cs:19-24

Data Structure

Field	Type	Description
Id	Guid	Unique identifier for the patient aggregate.
FirstName	string	Patient's first name (trimmed).
LastName	string	Patient's last name (trimmed).
Email	string	Normalized lowercase contact email.
DateOfBirth	DateTime	Patient's birth date.
PhoneNumber	string?	Optional contact number.
Status	PatientStatus	Current lifecycle state (Active, Suspended, Deleted).

Sources: Core/Scheduling/Scheduling.Domain/Patients/Patient.cs:7-13, Core/Scheduling/Scheduling.Infrastructure/Persistence/Migrations/SchedulingDbContextModelSnapshot.cs:234-273

Application Architecture

The context implements the CQRS (Command Query Responsibility Segregation) pattern using MediatR.

Command Flow

Commands represent intent to change the state of the system. Each command is validated against both business rules and security requirements before execution.

The diagram shows the processing of a command from the API request through validation and persistence.
Sources: WebApplications/Scheduling.WebApi/Controllers/PatientsController.cs:46-51, Core/Scheduling/Scheduling.Application/Patients/Commands/CreatePatientCommand.cs:36-45, WebApplications/Scheduling.WebApi/Program.cs:42-45

Security and Validation

Access to patient data is restricted based on user roles. The UserValidator base class ensures that only authorized roles (e.g., Admin, Doctor, Nurse) can execute specific commands.

• CreatePatient: Allowed for Nurse, Doctor, Admin.
• Suspend/Activate: Restricted to Doctor, Admin.
• Delete: Restricted to Admin only.

Sources: Core/Scheduling/Scheduling.Application/Patients/Commands/CreatePatientCommand.cs:38-40, Core/Scheduling/Scheduling.Application/Patients/Commands/SuspendPatientCommand.cs:27-29, Core/Scheduling/Scheduling.Application/Patients/Commands/DeletePatientCommand.cs:22-24

Infrastructure and Persistence

The Scheduling context uses SQL Server for persistence via Entity Framework Core. It implements the Outbox Pattern to ensure reliable event-driven communication.

Persistence Strategy

• Database: SQL Server (LocalDB or Docker).
• Mapping: The Patient aggregate is mapped to a Patients table. The Status property is converted to a string for database storage and back to a PatientStatus SmartEnum during retrieval.
• Reliability: MassTransit's Entity Framework integration is used for Outbox and Inbox tables (Scheduling_OutboxMessage, Scheduling_InboxState) to handle integration events asynchronously.

Sources: Core/Scheduling/Scheduling.Infrastructure/Persistence/Configurations/PatientConfiguration.cs:10-25, Core/Scheduling/Scheduling.Infrastructure/Persistence/Migrations/SchedulingDbContextModelSnapshot.cs:27-232, WebApplications/Scheduling.WebApi/Program.cs:48-52

API Endpoints

The PatientsController provides a RESTful interface for the Scheduling Bounded Context.

Method	Endpoint	Description	Auth Roles
GET	/api/patients/{id}	Retrieves a specific patient by ID.	Authorized
GET	/api/patients	Retrieves all patients, optionally filtered by status.	Authorized
POST	/api/patients	Creates a new patient record.	Nurse, Doctor, Admin
POST	/api/patients/{id}/suspend	Suspends an active patient.	Doctor, Admin
POST	/api/patients/{id}/activate	Re-activates a suspended patient.	Doctor, Admin
DELETE	/api/patients/{id}	Soft-deletes a patient record.	Admin

Sources: WebApplications/Scheduling.WebApi/Controllers/PatientsController.cs:17-80, Core/Scheduling/Scheduling.Application/Patients/Commands/CreatePatientCommand.cs:38-40, Core/Scheduling/Scheduling.Application/Patients/Commands/DeletePatientCommand.cs:24

Conclusion

The Scheduling Bounded Context serves as a robust example of a DDD-aligned module. It strictly enforces business invariants within the Patient aggregate, utilizes CQRS for clean separation of concerns, and leverages the Outbox pattern with MassTransit to maintain consistency in an event-driven ecosystem.