Application Architecture & Domain Design

If you were designing a patient-referral platform from scratch, the first architectural decision is not database technology or API style. It is where responsibility changes hands. Order origination, clinical review, booking, service execution, and result closure are related, but they are not the same domain object pretending to wear different hats.

This boundary-first view also makes team ownership clearer. It tells you which service should expose an API, which one should publish state changes, and which one is authoritative when statuses disagree.

A well-designed referral platform carries several identifiers at once. The patient identity is not the referral identity. The referral business id is not the appointment id. The appointment id is not the accession or performed-service id. Mixing those keys is how systems lose traceability when redirection, rebooking, or partial completion happens.

From an integration point of view, the cleanest architecture uses different contracts for different kinds of work. Service intent, local operational work, booked events, performed execution, and traceability records each need their own surface area because they answer different business questions.

You can still ship these layers inside one product, but the domain model should preserve their separate semantics. That is what keeps queue ownership, execution evidence, and final closure from collapsing into one opaque status machine.