ADR-004: Doctor as Role (Not Separate Service)

Status

Superseded by ADR-013.

Context

Doctors are central to our system - they create prescriptions, belong to organizations, and have professional credentials. We needed to decide:

• Separate Doctor Service: Own service for doctor management
• Doctor as Role in Identity: DoctorProfile as part of user identity
• Distributed: Doctor logic spread across services

Decision

We will treat Doctor as a role that a User plays, with DoctorProfile as a value object in the Identity service. No separate Doctor service.

Rationale

Why Not Separate Doctor Service?

A Doctor is not an aggregate root with its own lifecycle - they're always a User first:

User (Aggregate Root)
├── DoctorProfile (Value Object)
├── StaffProfile (Value Object)
└── Memberships (to Organizations)

Where Doctor Logic Lives

Operation	Service	Reason
Create/verify doctor profile	Identity	It's a user profile
Doctor search by specialization	Identity	Querying profile data
Doctor-Patient relationship	Prescription	Prescriptions link them
Doctor in an organization	Organization	Membership handles this
Doctor verification	Admin	Admin workflow
Doctor statistics	Prescription	Computed from prescriptions

When Would a Doctor Service Make Sense?

Consider extracting only when:

• Complex verification workflows (license verification against medical boards)
• Doctor discovery becomes core feature (search by location, availability, ratings)
• Doctor-specific settings (notification preferences, prescription templates)
• Regulatory requirements (doctor-specific audit trails)

Even then, these could be modules within Identity first.

Consequences

Positive

• Simpler architecture (no cross-service calls)
• Clear data ownership
• Doctor profile is co-located with user data

Negative

• Doctor-related queries may span services
• Need query layer for doctor search across contexts

Related Decisions

• ADR-003: Event-Driven Architecture
• ADR-005: Doctor Verification in Admin Service