Tweet
Tweet

Slide 1

Slide 1 text

DDD & REST Domain-Driven APIs for the web / olivergierke Oliver Gierke ogierke@pivotal.io

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

When designing REST APIs, what can we learn from DDD? “ 3

Slide 4

Slide 4 text

What does it take to bridge the worlds of DDD & REST? “ 4

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

6 http://www.infoq.com/minibooks/domain-driven-design-quickly

Slide 7

Slide 7 text

7

Slide 8

Slide 8 text

Value objects 8

Slide 9

Slide 9 text

Stringly typed code ! 9 class Customer { private Long id; private String firstname, lastname, email; … }

Slide 10

Slide 10 text

Stringly typed code ! 10 class SomeService { void createUser(…, String email) { // Valid email address? … } }

Slide 11

Slide 11 text

11 class Customer { private Long id; private Firstname firstname; private Lastname lastname; private EmailAddress emailAddress; … }

Slide 12

Slide 12 text

Stringly typed code ! 12 class SomeService { void createUser(…, String email) { // Valid email address? } }

Slide 13

Slide 13 text

Strongly typed code " 13 class SomeService { void createUser(…, EmailAddress email) { // Valid email address! } }

Slide 14

Slide 14 text

Make implicit
 concepts explicit. 14

Slide 15

Slide 15 text

Entities,
 Aggregates & Repositories 15

Slide 16

Slide 16 text

16 Order LineItem Product Invoice Customer Payment Address Email

Slide 17

Slide 17 text

Don’t get trapped by datastore thinking. 17

Slide 18

Slide 18 text

19 Order LineItem Product Invoice Customer Payment Address Email

Slide 19

Slide 19 text

Aggregates.
 Scopes of consistency. 20

Slide 20

Slide 20 text

21 Order LineItem Product Invoice Customer Payment Address Email

Slide 21

Slide 21 text

Aggregates.
 The key things
 to refer to. 22

Slide 22

Slide 22 text

23 Order LineItem Product Invoice Customer Payment Address Email

Slide 23

Slide 23 text

Bounded Context 24

Slide 24

Slide 24 text

Order LineItem Product Invoice Customer Payment Address

Slide 25

Slide 25 text

26 Shipping Accounting Catalog Orders User
 Registration

Slide 26

Slide 26 text

Domain Events 27

Slide 27

Slide 27 text

Explicitness
 maturity model 28

Slide 28

Slide 28 text

29 Level 0: CRUD

Slide 29

Slide 29 text

30 void addToOrder(Order order, Product product, Quantity quantity) { order.items.stream()
 .filter(it -> it.product.equals(product) .ifPresentOrElse( it -> it.increase(quantity), order.items.add(new LineItem(product, quantity)) ); }

Slide 30

Slide 30 text

30 void addToOrder(Order order, Product product, Quantity quantity) { order.items.stream()
 .filter(it -> it.product.equals(product) .ifPresentOrElse( it -> it.increase(quantity), order.items.add(new LineItem(product, quantity)) ); }

Slide 31

Slide 31 text

30 void addToOrder(Order order, Product product, Quantity quantity) { order.items.stream()
 .filter(it -> it.product.equals(product) .ifPresentOrElse( it -> it.increase(quantity), order.items.add(new LineItem(product, quantity)) ); } Aggregate code in clients !

Slide 32

Slide 32 text

31 Level 0: CRUD Level 1: Explicit operations

Slide 33

Slide 33 text

32 class Order { Order add(Product product, Quantity quantity) { this.items.stream()
 .filter(it -> it.product.equals(product) .ifPresentOrElse( it -> it.increase(quantity), order.items.add(new LineItem(product, quantity)) ); } }

Slide 34

Slide 34 text

32 class Order { Order add(Product product, Quantity quantity) { this.items.stream()
 .filter(it -> it.product.equals(product) .ifPresentOrElse( it -> it.increase(quantity), order.items.add(new LineItem(product, quantity)) ); } } Aggregate code in aggregate "

Slide 35

Slide 35 text

33 Level 0: CRUD Level 1: Explicit operations Level 2: Some operations as events

Slide 36

Slide 36 text

34 class OrderManagement { private final OrderRepository orders; private final Inventory inventory; @Transactional void completeOrder(Order order) { orders.save(order.complete()); order.doWithLineItems(item -> inventory.reduce(item.product, item.quantity)); } }

Slide 37

Slide 37 text

Feature creep 35

Slide 38

Slide 38 text

36 class OrderManagement { private final OrderRepository orders; private final Inventory inventory; private final LoyaltyProgram loyalty; @Transactional void complete(Order order) { orders.save(order.complete()); order.doWithLineItems(item -> inventory.reduce(item.product, item.quantity)); loyalty.update(order); } }

Slide 39

Slide 39 text

Synchronous, in-process
 remote communication 37 aka. „The Careless Microservice“

Slide 40

Slide 40 text

38 class OrderManagement { private final OrderRepository orders; private final RestOperations operations; @Transactional void completeOrder(Order order) { orders.save(order.complete()); // Update external systems operations.postForEntity(…); operations.postForEntity(…); } }

Slide 41

Slide 41 text

… and then we started to throw async, reactive and Hystrix at it. “ 39

Slide 42

Slide 42 text

… we tried to solve an architectural problem by adding more tech. “ 40

Slide 43

Slide 43 text

Domain events 41

Slide 44

Slide 44 text

42 class OrderManagement { private final OrderRepository orders; private final ApplicationEventPublisher publisher; @Transactional void completeOrder(Order order) { OrderCompletedEvent event = order.complete(); orders.save(order); publisher.publish(event); } }

Slide 45

Slide 45 text

43 class Inventory { private final InventoryItemRepository items; @EventListener void on(OrderCompletedEvent order) { // Update inventory } }

Slide 46

Slide 46 text

44 class EmailNotification { private final MailSender mailSender; @Async @TransactionalEventListener void on(OrderCompletedEvent order) { // Send emails } }

Slide 47

Slide 47 text

45 class OrderManagement { private final OrderRepository orders; private final ApplicationEventPublisher publisher; @Transactional void completeOrder(Order order) { OrderCompletedEvent event = order.complete(); orders.save(order); publisher.publish(event); } }

Slide 48

Slide 48 text

Move event creation
 to aggregates 46

Slide 49

Slide 49 text

47 // Super class contains methods with // @DomainEvents und @AfterDomainEventPublication class Order extends AbstractAggregateRoot { Order complete() { register(new OrderCompletedEvent(this)); return this; } }

Slide 50

Slide 50 text

48 class OrderManagement { private final OrderRepository orders; void completeOrder(Order order) { repository.save(order.complete()); } }

Slide 51

Slide 51 text

48 class OrderManagement { private final OrderRepository orders; void completeOrder(Order order) { repository.save(order.complete()); } } The aggregate is in charge "

Slide 52

Slide 52 text

49 Level 0: CRUD Level 1: Explicit operations Level 2: Some operations as events Level 3: CQRS / ES

Slide 53

Slide 53 text

REST 50

Slide 54

Slide 54 text

REST ≠ 
 CRUD via HTTP 51

Slide 55

Slide 55 text

Aggregates Identifiable
 Referable
 Scope of consistency 52

Slide 56

Slide 56 text

Resources Identifiable
 Referable
 Scope of consistency 53

Slide 57

Slide 57 text

Representation
 design matters 54

Slide 58

Slide 58 text

Hypermedia 55

Slide 59

Slide 59 text

Serving data and navigation information
 at the same time. 56

Slide 60

Slide 60 text

Hypermedia as
 the engine of
 application state 57

Slide 61

Slide 61 text

RESTBucks payment expected preparing cancelled ready completed 1 2 3 4 5 6

Slide 62

Slide 62 text

Method URI Action Step POST /orders Create new order 1 POST/PATCH /orders/{id} Update the order (only if "payment expected") 2 DELETE /orders/{id} Cancel order (only if "payment expected") 3 PUT /orders/{id}/payment Pay order (only if "payment expected") 4 Barista preparing the order GET /orders/{id} Poll order state 5 GET /orders/{id}/receipt Access receipt DELETE /orders/{id}/receipt Conclude the order process 6

Slide 63

Slide 63 text

How does the client
 know if a state
 transition is allowed? 60

Slide 64

Slide 64 text

Option 1:
 Inspecting the payload 61

Slide 65

Slide 65 text

63 GET /order/4711 { „createdDate“ : …, „status“ : „Payment expected“ … }

Slide 66

Slide 66 text

64 “Internationalize
 all user facing text!

Slide 67

Slide 67 text

Aaaargh! 65

Slide 68

Slide 68 text

Option 2:
 Inspecting
 hypermedia elements 66

Slide 69

Slide 69 text

Method URI Action Step POST /orders Create new order 1 POST/PATCH /orders/{id} Update the order (only if "payment expected") 2 DELETE /orders/{id} Cancel order (only if "payment expected") 3 PUT /orders/{id}/payment Pay order (only if "payment expected") 4 Barista preparing the order GET /orders/{id} Poll order state 5 GET /orders/{id}/receipt Access receipt DELETE /orders/{id}/receipt Conclude the order process 6

Slide 70

Slide 70 text

Method Resource type Action Step POST orders Create new order 1 POST/PATCH update Update the order 2 DELETE cancel Cancel order 3 PUT payment Pay order 4 Barista preparing the order GET order Poll order state 5 GET receipt Access receipt DELETE receipt Conclude the order process 6

Slide 71

Slide 71 text

69 GET /order/42 { „_links“ : { „cancel“ : { „href“ : … }, … „createdDate“ : …, „status“ : „Payment expected“ … }

Slide 72

Slide 72 text

Reducing decisions in clients to whether a
 link is present or not. 70

Slide 73

Slide 73 text

Trading domain knowledge with protocol complexity in clients. 71

Slide 74

Slide 74 text

72 Amount of domain knowledge in the client Amount of protocol knowledge in the client Coupling to the server Non-hypermedia
 based systems Hypermedia
 based systems

Slide 75

Slide 75 text

API evolvability is key
 in a system of systems 73 See „Evolving Distributed Systems“

Slide 76

Slide 76 text

RESTBucks payment expected preparing cancelled ready completed 1 2 3 4 5 6

Slide 77

Slide 77 text

Spring RESTBucks 75

Slide 78

Slide 78 text

Web Service Repository - Orders Spring Data Spring Data
 REST Payment Spring Data Manual
 implementation Manual
 implementation

Slide 79

Slide 79 text

Resources 77 Spring RESTBucks
 https://github.com/olivergierke/spring-restbucks Benefits of Hypermedia APIs
 http://olivergierke.de/2016/04/benefits-of-hypermedia/ Evolving Distributed Systems http://olivergierke.de/2016/10/evolving-distributed-systems/

Slide 80

Slide 80 text

Questions? 78