Applying Domain Driven Design to APIs and Microservices

James Higginbotham@launchany

Your API tells a story about your company and your vision

A great API design strategy is critical for API product adoption and

sustainable application development

Your APIs may not be considered “mission critical” like Stripe. But

your API design is a contract with your API consumers.

Your API design is composed of the capabilities (or “skills”)

you offer to developers

API Skills == “I want to…”

What skills do your APIs need to offer?

Outside-In API Design ApproachWeb

Application

API Design – “The Contract”

Internal ApplicationAPI Consumer Mobile

Application

API Design is an architectural concern that combines business, product design, and software engineering

Lack of Modularization = Regret

VS

Function-Based Module-Based

High cohesion internally for commonfunctionality

Loose coupling externally acrossmodules

High Cohesion + Loose Coupling

Public APIs encourageloose couplingbetween modules

API

Scoping rulesrestrict accessoutside of modules

X

API-Centric Software Design

Systems DesignSystem

Subsystem Subsystem

Module Module

Module Module

Subsystem Subsystem

Module Module

LEGO as Modular System Design

System

Sub-systems

Modules

API

API

API

System/Solution

Subsystem Subsystem

Subsystem

Module ModuleModule Module

Module ModuleModule Module

Module ModuleModule Module

Module Module

Module Module

Domain-Driven Design helps with identifying context

boundaries for complex APIs

Domain Driven Design (DDD) Maps domain concepts into software Heavy domain expert involvement Common vocabulary (“Ubiquitous Language”) Boundary-driven (“Bounded Context”) Applies learning over time

“I need to multiply two numbers together. So, I am building

a microservice architecture.”- almost everyone today

Microservice Architecture Loosely-coupled, service-oriented architecture Apply bounded context to limit cognitive load Independently deployable via automation Enable replaceability and experimentation Encourage composability of the business Best for larger teams

Applying Systems Designand Domain-Driven Design

to find API boundaries and resources

List Avail Inventory

DistributorAdd Product

to Order

CompleteOrder

Cancel Booking

Add Product to Inventory

Update Product Qty

LocateBooking

Redeem Booking

PointOf Sale

Remove Product

Customer

Operator

Operator

Order MgmtList Avail Inventory

DistributorAdd Product

to Order

CompleteOrder

Cancel Booking

Add Product to Inventory

Update Product Qty

LocateBooking

Redeem Booking

Operator

PointOf Sale

Remove Product

Customer

Operator

Inventory Mgmt

Fulfillment

Each subsystem has an API that exposes one or more endpoints

Order APIList Avail Inventory

DistributorAdd Product

to Order

CompleteOrder

Cancel Booking

Add Product to Inventory

Update Product Qty

LocateBooking

Redeem Booking

PointOf Sale

Remove Product

Customer

Operator

Inventory API

Fulfillment API

Operator

Identifying product opportunities becomes easier when we have

boundaries around the APIs

Order APIList Avail Inventory

DistributorAdd Product

to Order

CompleteOrder

Cancel Booking

Add Product to Inventory

Update Product Qty

LocateBooking

Redeem Booking

Operator

Remove Product

Inventory API

Fulfillment API

#1 #2`

PointOf Sale

For every API, ask: “What resources will it offer?”

Use domain-driven design to find business entities, relations,

state transitions, and events

Order APIList Avail Inventory

Add Product to Order

CompleteOrder

Cancel Booking

Add Product to Inventory

Update Product Qty

LocateBooking

Redeem Booking

Remove Product

Inventory API

Fulfillment API

Order API

Product Availabilities

Orders

ProductInventory

Bookings

Inventory API

Fulfillment API

Same entity (Products), Conceptually different to

the API context!

Availabilities- product

- date(s) avail- qty avail

Orders- bookings

- order total

Products- name

- avail schedule

Bookings- product- date(s)- status

Availabilities- product

- date(s) avail- qty avail

availabilityChanged()

Orders- bookings

- order total

created()updated()

Products- name

- avail schedule

created()removed()updated()

Bookings- product- date(s)- Status

redeemed()cancelled()

Availabilities- product

- date(s) avail- qty avail

availabilityChanged()

Orders- bookings

- order total

created()updated()

Products- name

- avail schedule

created()removed()updated()

Bookings- product- date(s)- status

redeemed()cancelled()

Order API Inventory API

Fulfillment API

Map Resources to the API

API composability using microservices

Public APIs target durability through external contracts.

Microservice APIs target evolution through learning and experimentation

Availabilities Service Orders Service

Products Service

Bookings Service

Orders HTTP API

Inventory HTTP API

Fulfillment HTTP API

Availabilities Service Orders Service

Products Service

Bookings Service

Orders HTTP API

Inventory HTTP API

Fulfillment HTTP API

Payment Service Refund Service

Alex

a Vo

ice

Skill

API

Gate

way

API

Gate

way

Mes

sagi

ng

…Microservice

…

API

…Microservice

…

API

…Microservice

…

API

…Microservice

…AP

I

Slac

k Ch

atbo

tW

eb +

M

obile

App

API

Gate

way

Microservice Architecture

The Composable World of APIs

Offers API

Inventory API

Bookings API

Identity API

Accounts API

Rewards API

Partners

InternalDevelopers

Public AppDevelopers

Consumers

Third-partyApproved Apps

Thank youJames Higginbotham

@launchanyhttp://bit.ly/api-skills