applying domain-driven design to apis and microservices - austin api meetup
TRANSCRIPT
Great API Design is critical for product adoption and long-term
API success
API design also tells a story about your company and your vision of what the world can
become.
Your API design defines the capabilities or skills your API
offers to developers
Credit: http://kinlane.github.io/university-api-workshop/apis/
Architecture is design
API Design is an architectural concern that combines business
drivers, product design, and software design
Outside-In API Design Approach
“My data model is not my object model”– Data model is for internal storage
“My object model is not my resource model”– Resources is for external, context-based collaboration– Object model is for internal software collaboration
“My resource model is not my representation model”– There are many ways to represent resources
e.g. JSON, XML, CSV, HTML
- Mike Amundsen, API-Craft Google Group- https://groups.google.com/forum/#!search/my$20resource$20model$20is$20not/api-craft/n2Efmju5nLM/
KUEyMOFIBAAJ
Applying Systems Designand Domain-Driven Design
What skills do your APIs need to offer?
Finding APIs through product and resource boundaries
Domain Driven Design (DDD)
Mapping domain concepts into software Heavy focus on domain expert involvement Common vocabulary (“Ubiquitous Language”) Boundary-driven (“Bounded Context”) Applies learning over time Based on Eric Evans' book "Domain Driven
Design”
Domain-Driven Design helps with identifying context
boundaries for complex APIs
Lack of Modularization = Regret
VS
Function-Based Module-Based
Microservice Architecture
Microservices are independently deployable, loosely-coupled components
Apply bounded context to limit cognitive load Benefit from heavy automation (CI/CD) Enable replaceability and experimentation Encourage composability of the business for
new products
Microservices require a renewed focus on
systems and API design
Modeling a System
System/Solution
Subsystem Subsystem
Module Module
Module Module
Subsystem SubsystemModule Module
LEGO as Modular System Design
System
Sub-systems
Modules
LEGO as a System of Systems
System
System
System
SystemSystem
Example: Marketplace Platform API
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 Mgmt
List 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
Driving API Design
Each subsystem has an API that exposes one or more endpoints
Order API
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
Inventory API
Fulfillment API
Operator
Identifying product opportunities becomes easier
when we have boundaries around the APIs
Order API
List 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 API
List 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
Availabilities
Orders
Products(Inventory)
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
Microservice APIs target replaceability
Availabilities Service
createAvailability()updateAvailability ()deleteAvailability ()
…availabilityChanged()
Orders ServicecreateOrder()
updateOrder ()deleteOrder ()
…created()updated()
Products ServicecreateProduct()
updateProduct ()deleteProduct ()
…created()
removed()updated()
Bookings ServicelookupBooking()
redeemBooking ()cancelBooking ()
…redeemed()cancelled()
Order API Inventory API
Fulfillment API
Orders HTTP API Inventory HTTP API
Fulfillment HTTP API
Voic
e Sk
ill
API
Prod
uct
API
Prod
uct
Mes
sagi
ng
…Microservice
…
API
…Microservice
…
API
…Microservice
…AP
I
…Microservice
…
APICh
atbo
tW
eb +
M
obile
App
API
Prod
uct
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
Summary
Great API design is critical for product adoption and long-term API success
API Design is an architectural concern that combines business drivers, product design, and software design
Systems design and DDD help with designing long-lasting APIs
Use microservices where appropriate to increase composability of your business or product
Be a storyteller using APIs
