ekwe7/zeeAccessCare-server

Zee Access Care is a digital healthcare platform connecting patients, hospitals, doctors, pharmacies, and HMOs through subscriptions, appointments, prescriptions, claims processing, and secure healthcare access management across Nigeria # Zee Access Care — Server Healthcare access & brokerage platform backend for Nigeria and Africa. Zee Access Care connects patients, doctors, and hospitals through a modular monolith, and is being built to eventually sit as a distribution/access layer over licensed HMOs before pursuing its own HMO/NHIA accreditation. > **Current phase:** Phase 1 — Core Clinical Loop > Patient registration → doctor search → appointment booking → consultation → prescription. No subscriptions, claims, payments, or admin console yet — see Roadmap. --- ## Table of contents - Architecture - Tech stack - Project structure - Getting started - Configuration - Running the app - Database & migrations - API overview - Authentication - Domain events - Testing - Module boundary rules - Roadmap - Contributing --- ## Architecture Zee Access Care is built as a **modular monolith with event-driven communication between modules**. - Each business capability (Identity, Patient, Doctor, Hospital, Appointment, Clinical) is a self-contained module with its own `controller`, `dto`, `model`, `repository`, `service`, `mapper`, and `event` packages. - Modules **never** reach into another module's internals. They communicate in two ways only: 1. **Synchronous facade calls** — a narrow public `XxxFacade` interface, used when a module needs an immediate answer (e.g. "does this doctor exist and is it verified?"). 2. **Domain events** — published via Spring's `ApplicationEventPublisher` and consumed with `@TransactionalEventListener(phase = AFTER_COMMIT)`, used for anything that's a *reaction* to something happening elsewhere (e.g. an appointment being marked completed unlocks the ability to record a consultation). - All modules currently share a single PostgreSQL database, but each module owns its own schema. This keeps ownership boundaries clean and makes extracting a module into its own service later (most likely `claims` or `clinical`, once volume justifies it) a mechanical change rather than a rewrit …