Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Designing APIs and Microservices Using Domain-Driven Design

10,859 views

Published on

Presented at GlueCon 2016. Applying good software engineering practices, system design, and domain-driven design for your public APIs and microservices

Published in: Software
  • Be the first to comment

Designing APIs and Microservices Using Domain-Driven Design

  1. 1. Applying Domain Driven Design to APIs and Microservices James Higginbotham @launchany
  2. 2. Your API tells a story about your company and your vision
  3. 3. A great API design strategy is critical for API product adoption and sustainable application development
  4. 4. Your APIs may not be considered “mission critical” like Stripe. But your API design is a contract with your API consumers.
  5. 5. Your API design is composed of the capabilities (or “skills”) you offer to developers
  6. 6. API Skills == “I want to…”
  7. 7. What skills do your APIs need to offer?
  8. 8. Outside-In API Design Approach Web Application API Design – “The Contract” Internal Application API Consumer Mobile Application
  9. 9. API Design is an architectural concern that combines business, product design, and software engineering
  10. 10. Lack of Modularization = Regret VS Function-Based Module-Based
  11. 11. High cohesion internally for common functionality Loose coupling externally across modules High Cohesion + Loose Coupling
  12. 12. Public APIs encourage loose coupling between modules API Scoping rules restrict access outside of modules X API-Centric Software Design
  13. 13. Systems Design System Subsystem Subsystem Module Module Module Module Subsystem Subsystem Module Module
  14. 14. LEGO as Modular System Design System Sub-systems Modules
  15. 15. API API API System/Solution Subsystem Subsystem Subsystem Module Module Module Module Module Module Module Module Module Module Module Module Module Module Module Module
  16. 16. Domain-Driven Design helps with identifying context boundaries for complex APIs
  17. 17. 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
  18. 18. “I need to multiply two numbers together. So, I am building a microservice architecture.” - almost everyone today
  19. 19. 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
  20. 20. Applying Systems Design and Domain-Driven Design to find API boundaries and resources
  21. 21. List Avail Inventory Distributor Add Product to Order Complete Order Cancel Booking Add Product to Inventory Update Product Qty Locate Booking Redeem Booking Point Of Sale Remove Product Customer Operator Operator
  22. 22. Order Mgmt List Avail Inventory Distributor Add Product to Order Complete Order Cancel Booking Add Product to Inventory Update Product Qty Locate Booking Redeem Booking Operator Point Of Sale Remove Product Customer Operator Inventory Mgmt Fulfillment
  23. 23. Each subsystem has an API that exposes one or more endpoints
  24. 24. Order API List Avail Inventory Distributor Add Product to Order Complete Order Cancel Booking Add Product to Inventory Update Product Qty Locate Booking Redeem Booking Point Of Sale Remove Product Customer Operator Inventory API Fulfillment API Operator
  25. 25. Identifying product opportunities becomes easier when we have boundaries around the APIs
  26. 26. Order API List Avail Inventory Distributor Add Product to Order Complete Order Cancel Booking Add Product to Inventory Update Product Qty Locate Booking Redeem Booking Operator Remove Product Inventory API Fulfillment API #1 #2 ` Point Of Sale
  27. 27. For every API, ask: “What resources will it offer?”
  28. 28. Use domain-driven design to find business entities, relations, state transitions, and events
  29. 29. Order API List Avail Inventory Add Product to Order Complete Order Cancel Booking Add Product to Inventory Update Product Qty Locate Booking Redeem Booking Remove Product Inventory API Fulfillment API
  30. 30. Order API Product Availabilities Orders Product Inventory Bookings Inventory API Fulfillment API Same entity (Products), Conceptually different to the API context!
  31. 31. Availabilities - product - date(s) avail - qty avail Orders - bookings - order total Products - name - avail schedule Bookings - product - date(s) - status
  32. 32. 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()
  33. 33. 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
  34. 34. Map Resources to the API
  35. 35. API composability using microservices
  36. 36. Public APIs target durability through external contracts. Microservice APIs target evolution through learning and experimentation
  37. 37. Availabilities Service Orders Service Products Service Bookings Service Orders HTTP API Inventory HTTP API Fulfillment HTTP API
  38. 38. Availabilities Service Orders Service Products Service Bookings Service Orders HTTP API Inventory HTTP API Fulfillment HTTP API Payment Service Refund Service
  39. 39. Alexa VoiceSkill API Gateway API Gateway Messaging … Microservice … API … Microservice … API … Microservice … API … Microservice … API Slack Chatbot Web+ MobileApp API Gateway Microservice Architecture
  40. 40. The Composable World of APIs Offers API Inventory API Bookings API Identity API Accounts API Rewards API Partners Internal Developers Public App Developers Consumers Third-party Approved Apps
  41. 41. Thank you James Higginbotham @launchany http://bit.ly/api-skills

×