In the previous article, I covered the basic concepts and introduced a 5-step process for applying DDD in practice. Today, I will bring you a bigger challenge. In this article, we will work through an example by designing a healthcare platform.

I. Healthcare Platform Requirements

1. Scenario

General Hospital A has been providing City X‘s citizens with a wide range of healthcare services. Its routine operations rest on its Data Center on-premises with a legacy healthcare platform composed of heterogeneous monolithic, SOA apps that were designed and built up 2 decades ago. The growing population results in the high demand on the high load, high quality and multi-specialties of healthcare services.

With the as-is legacy healthcare platform, its day-to-day operations undergo a series of pain-points, incidents, and limitations including inflexible business functionalities, slow response time under high load (even saturation), API management, resilience, observability, maintainability, expandability, deployability… To address these shortcomings of the as-is platform, the hospital hires a multi-national IT consulting firm who advises the Hospital Leader Board to modernize their as-is healthcare platform by capitalizing on advantages and strengths of cloud computing, Microservices as a trendy architectural style, Intelligent Analytics. As a SA, you are tasked with architecting a MSA-based healthcare platform for Hospital Leader Board and development teams with requirements below.

2. Business Specification

The healthcare platform manages information about patients (demographics, medical history, insurance data). It also manages Electronic Medical Records (EMR) including medical tests (blood, urine...), imaging studies (X-ray, CT/MRI scans, Ultrasound...). It allows patients to online schedule appointments with doctors in advance. Patients can follow the normal medical procedure by online booking doctors, or offline registering for examinations, paying service bills in advance. Receptionists receive patients' requests and arrange appointments with doctors. On appointment days, patients go into the hospital, show up at Examination Department, doctors examine patients, request medical tests, if necessary. Based on symptoms, test results, doctor will diagnose diseases, decide on treatments (surgery, medication, therapies), prescribe medicine. Patients pay bills for additional service fees, if any, deposit money in case they undergo inpatient treatments and monitoring. Patients can also claim insurance if available. The healthcare provider provides emergency, check-up services, inpatient and outpatient treatment services to the City's citizens.

3. Technical Specificaiton

The platform integrates with External Identity Provider, External Payment Gateway, External Insurer, Internal Accounting and Logistic systems. It supports both web browsers and mobiles as clients.

II. Requirement Analysis

We need to design a new MSA-based healthcare platform to replace the legacy system (on-premises, monolithic + SOA):

• Capable of handling thousands of concurrent users

• Capitalizing on advantages and strengths of cloud computing, microservices and cloud app best practices.

• Implement data replication and data recovery strategies to prevent data loss

• Utilize distributed systems principles to ensure high availability and fault tolerance

• Maintain data consistency across microservices

Therefore, we need to decompose the Healthcare Platform as the whole business domain into corresponding subdomains/bounded contexts.

Functional Requirements

• Manages:

  • Patient information (demographics, medical history, insurance data)

  • Electronic Medical Records (EMR) including medical tests (blood, urine...), imaging studies (X-ray, CT/MRI scans, Ultrasound...)

• Allows patients to online schedule appointments with doctors in advance

• Patients can pay service bills, claim insurance

• Receptionists receive patients' requests, arrange appointments with doctors

• Receptionists/Doctors handle medical procedures, store medical history,... into the system

• Provides emergency, check-up services, inpatient and outpatient treatment services to the City's citizens.

• Integrates with External services (Identity Provider, Payment Gateway, Insurer), Internal services (Accounting, Logistic, Resource Management).

  

Notes: We must clarify the scope of the new platform with customers. For instance, Resource Management, Pharmacy Management might not be explicitly mentioned in the requirements, but it's important to confirm whether it should be included.

Non-functional Requirements

• Capable of handling thousands of concurrent users

• Data replication and data recovery

• High availability with minimal latency

• The system should be scalable and efficient

• Data encryption for all layers, end-to-end encryption

III. Subdomain Decomposition

I often apply the 4+1 Architectural View Model for my architectural designs, providing comprehensive perspectives for stakeholders with 5 different views. I'll share details about this model and complete designs for our healthcare platform in another article. In this article, I'll focus only on the Logical View, including our subdomain decomposition process. Btw, I will skip Ubiquitous Language table creation since I'm the only one working on the project 😂

1. EventStorming Workshop

To clearly decompose the entire domain, we first need to review the main business process:

I simulated an EventStorming workshop and identified all key events and created a following Big Picture:

2. Identify Bounded Contexts

From the above Big Picture, I can identify natural boundaries between subdomains.

Finally, I categorized subdomains into the following three groups:

Core Subdomains

• Treatment Service: manages medical process during patient’s examination, inpatient & outpatient treatments

• EMR (Electronic Medical Records): manages Electronic Medical Records (EMR) including medical tests (blood, urine...), imaging studies (X-ray, CT/MRI scans, Ultrasound...)

• Patient Management: manages patient information, medical check history,…

• Emergency Services: emergency and urgent care services

• Check-up Services: handle check-up processes, check-up services for personal/enterprises

Supporting Subdomains

• Reception Service: manages patient reception, registration, guidance

• Appointment Scheduling: manages appointments with doctors (online and offline registration)

• Billing & Payment: handles payments and bills/invoices for medical services

• Insurance Management: handles patients claims, manages insurance information

Generic Subdomains

• Account management: handle the authentication/authorization with external Identity Provider, manage accounts, roles,…

• Notification: handles notification services (SMS, email, mobile notifications)

• Reporting/Analytics: manages/generates reports and dashboards for monitoring and data-driven decisions.

3. Identify Context Map

As I mentioned in the previous post, I only use upstream/downstream relationship for Context Map to keep it simple and more readable. Integration patterns like Anti-Corruption Layer (ACL), Open Host Service (OHS),… with more details might be defined in the architecture design.

As this is our example, I didn’t have any workshops with business team (very important) but relied on my knowledge of healthcare systems and my experience with the My HMUH mobile app.

In complex domains, it can be challenging to capture every relationship between subdomains on a single Context Map. Therefore, it's a good idea to split it into multiple maps.

Importantly, building Context Map will reveal any conflicts or redundancies in the business flow, helping to refine the design before proceeding to detailed development.

IV. Conclusion

Phew… We've went through an interesting example of applying DDD to a healthcare platform design, exploring how to break down complex medical processes into subdomains and identify Context Map between them. It took me a lot of time to complete the DDD series.

Once again, I hope this helps everyone get a good start with DDD and be ready to handle larger projects. If you find it useful, feel free to share.

References

• Mr Dung Ho - Presales Consultants, Solution Architect - FPT Software