How to use both a Domain Driven Design approach and achieve the benefits of API-Led Connectivity 

Our client engagements often start with the following question, “how do I determine which APIs to build, and in what order?”. The reason for the question is simple: they have project teams banging down their door with integration requirements, and yet they know that if they simply build to their specifications they will repeat the mistakes of the past, where these APIs they end up with are too specific to be used in other projects. How do we balance these seemingly competing objectives of project speed and reusability needs they ask? 

A couple of approaches have gained popularity in recent times that are touted as the answer to API prioritisation. These are Domain Driven Design (DDD) and API-Led Connectivity (ALC).  DDD is used widely by software development teams for modelling a software system based on the core domain and its concepts. API-Led Connectivity (ALC) has gained traction in recent years as it is pushed by leading API vendors as a method for unlocking business agility and based upon Gartner’s PACE layered application strategy. But which one should you use? 

The short answer is you should use both but let’s look at why and more importantly how to marry the two in practice. 

As a quick recap, DDD is an approach to software development that provides a set of principles and practices for designing complex software systems that reflect the real-world domain they are intended to serve. The central idea of DDD is to align the software design with the business domain, ensuring the APIs are more maintainable, understandable, and adaptable. By placing the domain at the heart of the design process, DDD aims to capture the deep understanding of the business context and express it in the software design and implementation. DDD divides a large software system into smaller, well-defined bounded contexts. Each bounded context represents a specific subdomain of the overall system and contains its own models, business rules, and language. This helps in managing complexity and enables teams to focus on specific areas without getting overwhelmed by the entire system. These domain models are described in a common shared language between the technical and business team in order to foster better collaboration and understanding. 

The critique of DDD is that it says little about how to access the data and events that are held in the core business applications. Nor does it say much about the needs of consumers – who often need to write lots of custom code in order to translate the output of domain entities into what they need. This can lead to teams building monolithic APIs for specific business functions targeted at one consumer type with tightly bound integration code to the supporting data and services.  As a response to this critique, API-Led developed as an approach to designing and building APIs that emphasises the creation of reusable, modular components that can be combined to create flexible, scalable APIs. It consists of three distinct layers: System APIs for accessing data and transactions in core systems, Process APIs that orchestrate and combine the system APIs to implement specific business processes or workflows, and Experience APIs that provide interfaces for the different consumer channels. While API-led provides an easy way of determining System APIs, as they are simply determined by the underlying system of record, or the experience APIs, as they are determined by the user interface required, it lacks a solid method for determining what are the process APIs. 

This is where DDD comes back in. By combining API-Led with DDD, it can help to ensure that the API design is based on a solid understanding of business domains thereby capturing all the required services and functions, and also ensure that the APIs are designed in a modular, scalable way that supports the organisation’s broader integration goals and importantly fosters a culture of reuse which is critical in large programs to reduce the amount of code that has to be created.

To put it in slightly more practical terms, we advocate using an API-Led architecture that is determined through a domain driven approach. DDD is used to identify all the services required to support the business processes and entities, while API-led architecture specifies the underlying System APIs required to support the Business APIs and the overarching Experience APIs to provide tailored interfaces to specific end consumers e.g. a mobile app, an M2M connection, an IOT device, or tailored for a particular partner or supplier. In more complex use cases you can also use the API led approach to decompose the Business APIs further to facilitate reuse and scalability. For example, a development team might use DDD to create a domain model that represents the key concepts and relationships of a particular business domain, such as e-commerce. They could then use API-led architecture to design a set of modular APIs that expose the functionality of the e-commerce system in a way that is easy to use and integrate with other systems. 

By combining these two approaches, your organisation can create APIs that are not only well-designed from a technical perspective, but also closely aligned with the needs and requirements of the business. This can help to ensure that the API is effective in meeting the needs of its users and supporting the organisation’s broader goals. In our next blog we will break down an example into domain models and an API architecture to demonstrate this approach, but hopefully this blog has given an easy introduction into Domain Driven API design.