Doctor Appointment Booking System
This is a basic doctor appointment booking system, a web and mobile-based app allowing patients to schedule medical appointments online, manage bookings, and receive reminders. Doctors will use the system to manage their different schedules; hospital administrators will be able to monitor appointment statistics and optimize scheduling efficiency. A notification service will be included to remind patients about upcoming appointments.
- Python 3.10 or higher
pip(Python package manager)git- A GitHub account
git clone https://github.com/your-username/doctor-appointment-booking.git
cd doctor-appointment-booking
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt| Feature | Status | Contribution Guide | Label |
|---|---|---|---|
| Integrate Redis for caching doctor availability | Planned | Open Issue | Enhancement |
| Support optional email reminders for patients | Planned | Open Issue | Enhancement |
| Add appointment filtering by date and doctor | Planned | Open Issue | Enhancement |
| Improve formatting in README.md | Planned | Open Issue | Good First Issue |
| Add 404 handler for unknown routes | Planned | Open Issue | Good First Issue |
| Fix typo in error message for doctor login failure | Planned | Open Issue | Good First Issue |
| Add unit tests for NotificationService | Planned | Open Issue | Good First Issue |
| Add docstrings to all service methods | Planned | Open Issue | Good First Issue |
- Use of Generics: Avoids duplication across entity repositories by abstracting common CRUD operations into the
IRepositoryinterface, reducing repetitive code. - Entity-Specific Interfaces: Allows for specialized queries, such as
find_by_email()inIPatientRepositoryorfind_by_specialization()inIDoctorRepository. - Adherence to SOLID Principles:
- Promotes the Interface Segregation Principle by ensuring interfaces are specific to the needs of each entity.
- Encourages the Dependency Inversion Principle by making components depend on abstractions rather than concrete implementations.
- Testability and Flexibility: Enhances the testability of the data layer, making it easier to perform unit testing and mocking in services.
- Highly Testable: Easily inject mocks or stubs during unit testing.
- Separation of Concerns: Services depend on abstractions rather than specific implementations.
- Explicit and Flexible: Particularly useful when working with multiple implementations (e.g., in-memory, database, cache).
- Framework Compatibility: Works seamlessly with frameworks like FastAPI, Django, and Flask (with DI extensions).
- Dynamic Instantiation: Useful for creating multiple variants dynamically.
- Hidden Dependencies: Can obscure dependencies, making unit testing more challenging.
- Potential Tight Coupling: May lead to tightly coupled code if not carefully managed.
- Use Case: Centralized creation of different user roles like Patient, Doctor, Admin.
- Why: Simplifies user creation logic and isolates instantiation.
- Use Case: Sending notifications via different channels (Email, SMS).
- Why: Allows flexibility to extend new notification types without changing the core logic.
- Use Case: Rendering UI components (e.g., buttons) depending on platform (Web or Mobile).
- Why: Ensures consistent UI elements across platforms.
- Use Case: Constructing complex Appointment objects step-by-step.
- Why: Enhances clarity and flexibility when creating appointments with multiple fields.
- Use Case: Quickly duplicating report templates for different users.
- Why: Avoids costly re-creation and ensures performance.
- Use Case: DatabaseConnection for the backend system.
- Why: Ensures only one global connection is created to avoid conflicts and resource waste.