Navigating the complexities of a rapidly scaling healthcare platform requires more than just code; at QCon London 2025, Leander Vanderbijl shared his company’s journey of how domain-driven design (DDD) became instrumental in bringing order to a rapidly growing and increasingly complex healthcare platform. His talk highlighted the crucial steps taken to move from a system of interdependent services lacking clear guidelines to a more coherent, business-focused architecture.
Vanderbijl painted a picture of the company’s early days, when rapid growth led to a web of interconnected services without a unifying structure—a situation he aptly described as “spaghetti” architecture. This complexity made it difficult to understand core business functionalities and hindered further development. Recognizing the unsustainable nature of this architectural tangle, a small, dedicated team was assembled to clarify the business direction and establish unified goals through the lens of DDD.
The organization’s rapid expansion had outpaced its initial models for managing data, services, and customer interactions. Attempts to completely rebuild the system were deemed impractical. Instead, the team opted for an in-situ approach to introduce DDD principles compatible with the existing infrastructure.
The DDD initiative identified three core domains: healthcare services, payment systems, and a support system for services that didn’t neatly fit into the other two. This foundational understanding paved the way for significant architectural changes.
One key strategy employed was dubbed the “Take That” approach. This involved amalgamating similar functionalities and simplifying the interactions between services. A prime example was reorganizing medical services, separating core medical functions from ancillary services while ensuring effective data handling.
Beyond the “Take That” consolidation, Vanderbijl described two other key strategies:
- The “Robbie Williams” strategy involved identifying and retaining essential, well-functioning services while discarding redundant or poorly designed elements.
- The “Prince” approach focused on adapting and rebranding existing services that held value but required significant enhancements or a more precise identity within the new domain model.
Furthermore, the team drew inspiration from the Fast Healthcare Interoperability Resources (FHIR) model to structure medical data. This adoption aimed to improve data queries, enhance interoperability, and create a more standardized approach to handling healthcare information within their domain.
Vanderbijl emphasized that the adoption of DDD is not a one-time fix but rather an ongoing journey. He stressed the critical need for adaptability and the continuous evaluation of business requirements. The focus shifted from strictly adhering to product demands to prioritizing the underlying domain functionalities, ensuring the architecture remained aligned with the core business.
The talk concluded with a powerful reminder that domain-driven design is an evolutionary process, requiring a commitment to continuous improvement and a willingness to adapt as the business and its understanding of the domain evolve. By embracing these principles, the organization moved from a state of architectural chaos towards a more structured, maintainable, and business-aligned future.
After the session, InfoQ spoke with VanderBijl and asked him the following questions:
InfoQ: Looking back at the ‘Take That,’ ‘Robbie Williams,’ and ‘Prince’ strategies, was there one that proved more challenging to implement than the others, and what were the key hurdles you faced with that particular strategy?
VanderBijl: The Robbie Williams approach was the most challenging of the three strategies. With the Take That approach, we had existing code to lift and shift into a new service wholesale (or predominantly wholesale). With the Prince approach, we built a new service beside an existing one. The Robbie Williams approach required us to remove and, crucially, disentangle existing code in situ. There was a challenge in removing and migrating functionality to a new single endpoint, and we had difficulties keeping the changes small. Due to the extreme coupling, small changes often fanned out to create a significant impact, and it took a lot of effort and trial and error to work out how far to go with a given change and when to stop.
InfoQ: You mentioned a small team pinpointing the primary objectives and domains. What was the biggest challenge in that initial domain discovery phase, and what key insight finally helped the team solidify those core domains?
VanderBijl: We kept our initial group small when pinpointing our primary objectives and domains to allow us to move quickly and to keep the “what about-ery” and the concern about edge cases to a minimum. We decided early on that a reasonable target domain structure was better than a perfect one. We agreed the domain structure would be a living-breathing document that was allowed to change; therefore, keeping the group small made it easy for us to progress and reach consensus quickly. Ensuring all teams knew this was a living document made it easier for them to accept and adopt.
We were pleasantly surprised at how easily we quickly identified our primary domains, particularly when we ignored any of the existing dependencies and all of the what-ifs and edge cases. By knowing that the domain doesn’t need to be perfect and can evolve, we got to a simple, concise, and easy-to-digest schema that made sense very quickly. There is still a lot of work required to split the domains into more complex subdomains, but this is an iterative process and, since we reduce the cognitive load with every subdomain, it becomes easier and easier to do.
