Service boundaries
| Owner | Authoritative responsibility | Cross-service relationship |
|---|---|---|
| Audit | Immutable change histories and scoped read capabilities | Admin/Organization own HTTP; providers append within business transactions |
| Identity | Credentials, accounts, tokens, sessions, account profile | Supplies account/authentication capabilities |
| Doctor | Professional profiles, license, specialization, onboarding orchestration | Uses Identity and Organization-owned capabilities |
| Organization | Organizations, teams, ordinary members, doctor affiliations, invitations, join requests | Owns relationships rather than credentials |
| Subscription | Plans, subscriptions, snapshots, invoices, manual payments | Supplies billing capabilities to Admin and organization views |
| Medicine | Manufacturer, generic, brand, and drug catalog | Supplies read APIs and curated Admin management |
| Patient | Organization-scoped demographics, contact details and addresses | Supplies curated patient lookups to clinical workflows |
| Prescription | Doctor-owned clinical documents, drafts, issuance, cancellation, derived history | Uses patient/doctor display data and organization context |
| Admin | Platform administration and privileged orchestration | Delegates provider-owned changes; owns admin roles/verification workflow |
| Notification | Templates, delivery, and notification state | Sends via shared email boundary and SMS adapter |
This table describes ownership, including planned capabilities. It is not an implementation checklist: consult each service guide for current behavior.
Ordinary organization members and professional doctor affiliations are distinct. Assigning a doctor member role does not create a doctor profile or affiliation. Prescriptions are owned by their author; the organization supplies context. Patient demographics and prescription-derived clinical history are separate responsibilities.
Consumers import another service's public package and receive implementations through composition-root wiring. Admin uses AdminOrganizationService for organization and membership operations and AdminIdentityService for account provisioning and lookups. Other workflows retain their curated capabilities. HTTP DTOs and storage entities must not become accidental cross-service contracts. Use events for projections and post-change reactions, not commands requiring immediate request-time success.
ADR-008 documents the detailed responsibilities; ADR-012 describes the capability boundary. ADR-004's earlier doctor-as-role decision is superseded by ADR-013.
Clinical input catalogs use shared models in pkg/types/domain and interfaces in pkg/types/ports as an explicit exception to the service-public package convention. Domain models, commands, queries, stable errors and validation remain separate from service/repository ports. Both packages are serialization-free and import no service/HTTP/SQL packages. Prescription owns implementation/storage, Doctor owns authenticated suggestion GETs, and Admin owns authorized management HTTP. The services are AdminClinicalSuggestionService (both catalogs' CRUD) and DoctorClinicalService (both autocomplete queries). Repository ports are injected only into Prescription implementations, never Doctor/Admin. HTTP DTOs remain service-local.