Building a Domain Platform- laying the foundation

5 min readApr 25, 2023

Today the term ‘Platform’ is very overloaded and has many interpretations. At times it is used to mean ‘Platform as a Service’ which refers to specific technology capabilities provided by Cloud Computing providers. It is also used to refer to social platforms (like Facebook, Twitter) which enable interactions between content creators and content consumers. A recent addition is Internal Developer Platform(IDP) which consists of different technologies and tools, glued together to provide golden paths and enable developer self-service.

In this article however, we will discuss about Domain Platform — what is a domain platform and its impact on enterprises’ value streams (its products and solutions), and then look into a high level hypothetical HealthCare Domain Platform.

What is a Domain Platform ?

Domain Platform is an ecosystem of reusable assets (services, models, workflows etc.) with well-defined interfaces which can be externally consumed to build multiple end-user facing products.

The capabilities of domain platform can be reused differently to achieve new and varied outcomes i.e. end-user facing products and solutions.

Figure 1: Leveraging platform for product development

Why Domain Platform?

Benefits of domain platform for an enterprise are many fold:

Streamline implementation of common business workflows across different products by providing them as platform capabilities. This ensures consistent end user experience.
Accelerate product development and delivery by reusing domain capabilities provided by platform across multiple products in an enterprise. Domain platform helps bootstrap product development and reduces cognitive load on product teams.
Reduce security, regulatory and privacy risks in individual products by addressing them as part of common capabilities in platform. This becomes more prominent for businesses like healthcare which operates in a highly regulated environment.
Improve reliability and resiliency of products that relying on platform capabilities that are built and managed by dedicated domain and technical SMEs in platform team.

However, domain platform is not a silver bullet and may not be viable in all cases. Before building a domain platform, enterprises should do proper due diligence — Are there enough functional commonalities among the products which can be addressed by the platform ? Would the enterprise accrue tangible benefit after offsetting overhead of having a dedicated platform team ?

Mental model of a Domain Platform

Figure 2. below provides a mental model of a domain platform that can be applied to any business domain.

Platform Core includes core domain models, business workflows and decisions, validations which does not vary with use cases. Many industries already has standard domain models (such as TM Forum SID for Telecommunications or FHIR for Healthcare) that can be leveraged to create canonical data model. Similarly there are standard business processes, workflows and rules for many industries.

Platform Services are headless services which provide business functionalities and are unaware of products which use them.

These services are invoked as part of business execution flows configured in products. Proper identification of services and their interrelationships is key here, Bounded Context as prescribed in Domain-Driven Design (DDD) can be utilised for that.
Platform services publish business events to message broker which are consumed by other platform services to build functionality in a loosely coupled manner.
May use externally provided service or products (open-source or commercial) to build intended capability. Any integration with external provider is handled by platform service and should be abstracted from products. Proper build-vs-buy analysis is needed before deciding usage of external providers.
Uses entity models and business rules defined in Platform Core and extend them where needed.

Platform API exposes platform services for external consumption and handles cross-cutting concerns like authentication, authorization, rate limiting and call routing. Many of these cross-cutting concerns can be enforced using an API Gateway.

At the bottom, we have Technology Infrastructure. Domain platform capabilities are build on the shoulders of many technology innovations including Cloud (compute, storage, network), Event stream, DevOps, Observability, SRE etc.

Interactions between Product and Platform services

Product service can call a platform service API which encapsulates discrete business functionality needed by the product. Applicable in cases where — i)business logic can be handled by a single platform services or ii) product service wants to manage overall workflow and use platform service for a few individual step(s) in the workflow.
Product service can call a platform service API which triggers a multi-step workflow execution involving multiple product services. Event-driven orchestration can be used to model multi-step workflow and implemented using workflow engine and event stream.

Figure 3: Platform feature involving multi-step workflow

Platform services can publish events to message broker which is consumed by product services asynchronously to build custom functionality .
Platform services can provide Webhooks to send message to product service when specific events happen.

Attributes of domain platform

Followings are some key attributes that affect the success of a domain platform.

Easy onboarding: To be able to use platform’s capabilities, product teams would need proper documentation. Well documented API specs, user guides, project templates and trainings will help adoption of platform services in a quick and simple way.
Easy to consume: Product services should expose well-defined APIs so that they are easy to discover and invoke from product services. Platform APIs should abstract out internal implementation details of platform services. Additionally products should be able to pick and choose only relevant platform services.
Externally programmable: Platform should provide hooks to support customisation of default behavior wherever needed by products. There are multiple ways to achieve this based on use case. Platform services can use HTTP-based Webhooks to communicate different events to product service. Product service could then implement the customised functionality needed in response to that event. Or if the amount of messages is large, platform service could publish to message broker for product service to consume and implement custom functionality.
Standard based: Platform should adopt industry standards (both domain and technology standards) wherever applicable. This ensures that platform is aligned with industry best practices and remains fit for future.

Illustrative Healthcare Domain Platform

Figure 4 shows a bird’s eye view of a cloud native healthcare domain platform based on the mental model (Figure 2). Note: This is a hypothetical representation used only for illustration, actual platform services/capabilities will vary based on requirements of products/solutions that it caters to.

Closing notes

Domain platform provides capabilities which can be reused to accelerate development of products and solutions. In this article we have discussed a mental model of domain platform, interaction patterns between products and platform, and some key attributes of domain platform.