DDD & REST — Domain-Driven APIs for the web

Slides of the talk I gave at OOP 2017, Munich.

@springcentral

Transcript

1. DDD & REST Domain-Driven APIs for the web / olivergierke Oliver Gierke ogierke@pivotal.io
4. When designing REST APIs, what can we learn from DDD? “ 4
5. What does it take to bridge the worlds of DDD & REST? “ 5
7. 7 http://www.infoq.com/minibooks/domain-driven-design-quickly
10. Value objects 9
11. Stringly typed code 10 class Customer { private Long id; private String firstname, lastname, email; … }
12. Stringly typed code 11 class SomeService { void createUser(String firstname, String lastname) { … } }
13. Stringly typed code 12 class SomeService { void createUser(…, String email) { // Valid email address? … } }
14. 13 class Customer { private Long id; private Firstname firstname; private Lastname lastname; private EmailAddress emailAddress; … }
15. 14 final class EmailAddress { private final String value; static EmailAddress of(String source) { if (!source.matches(…)) { throw new IllegalArgumentException(…); } … } }
16. If you receive an
 instance of a value 
 type, you can be 
 sure it’s valid. 15
17. Stringly typed code 16 class SomeService { void createUser(…, String email) { // Valid email address? } }
18. Strongly typed code 17 class SomeService { void createUser(…, EmailAddress email) { // Valid email address! } }
19. Make implicit
 concepts explicit. 18
20. Entities,
 Aggregates & Repositories 19
21. 20 Order LineItem Product Invoice Customer Payment Address Email
22. Don’t get trapped by datastore thinking. 21
23. 22 Order LineItem Product Invoice Customer Payment Address Email
24. Aggregates.
 Scopes of consistency. 23
25. 24 Order LineItem Product Invoice Customer Payment Address Email
26. Aggregates.
 The key things
 to refer to. 25
27. 26 Order LineItem Product Invoice Customer Payment Address Email
28. Bounded Context 27
29. Order LineItem Product Invoice Customer Payment Address
30. 29 Shipping Accounting Catalog Orders User
 Registration
31. 29 Shipping Accounting Catalog Orders User
 Registration Accounting Payment information Billing Address Shipping Shipping address Customer
32. 29 Shipping Accounting Catalog Orders User
 Registration Accounting Payment information Billing Address Shipping Shipping address Customer Product
33. Canonical references
 but data duplication 30
34. Domain Events 31
35. Explicitness
 maturity model 32
36. 33 Level 0: No events at all
37. 33 Level 0: No events at all Level 1: Explicit operations
38. 34 void addToOrder(Order order, Product product, Quantity quantity) { Optional<LineItem> item = order.items.stream()
 .filter(it -> it.product.equals(product)); // Update existing item or create new one if (item.isPresent()) { item.ifPresent(it -> it.increase(quantity)); } else { order.items.add(new LineItem(product, quantity); } }
39. 35 class Order { Order add(Product product, Quantity quantity) { // Code goes here… } }
40. If you’re calling two setters in a row, you’re missing a concept. 36
41. 37 Level 0: No events at all Level 1: Explicit operations
42. 37 Level 0: No events at all Level 1: Explicit operations Level 2: Some operations as events
43. 38 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)); } }
44. Feature creep 39
45. 40 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); } }
46. Synchronous remote communication 41
47. 42 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(…); } }
48. Domain events 43
49. 44 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); } }
50. 45 class Inventory { private final InventoryItemRepository items; @EventListener void on(OrderCompletedEvent order) { // Update inventory } }
51. 46 class EmailNotification { private final MailSender mailSender; @Async @TransactionalEventListener void on(OrderCompletedEvent order) { // Send emails } }
52. 47 class OrderManagement { private final ApplicationEventPublisher publisher; private final OrderRepository orders; @Transactional void completeOrder(Order order) { OrderCompletedEvent event = order.complete(); orders.save(order); publisher.publish(event); } }
53. 48 // Super class contains methods with // @DomainEvents und @AfterDomainEventPublication class Order extends AbstractAggregateRoot { Order complete() { register(new OrderCompletedEvent(this)); return this; } }
54. 49 class OrderManagement { private final OrderRepository orders; void completeOrder(Order order) { repository.save(order.complete()); } }
55. 50 Level 0: No events at all Level 1: Explicit operations Level 2: Some operations as events
56. 50 Level 0: No events at all Level 1: Explicit operations Level 2: Some operations as events Level 3: Event Sourcing
57. Domain events as
 state transitions. 51
58. Expose important
 events to interested parties via feeds. 52
59. REST 53
60. REST ≠ 
 CRUD via HTTP 54
61. Representation
 design matters 55
62. Aggregates Identifiable
 Referable
 Scope of consistency 56
63. Resources Identifiable
 Referable
 Scope of consistency 57
64. Hypermedia 58
65. Serving data and navigation information
 at the same time. 59
66. Hypermedia as
 the engine of
 application state 60
67. RESTBucks payment expected preparing cancelled ready completed 1 2 3 4 5 6
68. 62 GET /order/4711 { „_links“ : { „cancel“ : { „href“ : … }, … „createdDate“ : …, „status“ : „Payment expected“ … }
69. How does the client
 know if a state
 transition is allowed? 63
70. Option 1:
 Inspecting the payload 64
71. 65 GET /order/4711 { „_links“ : { „cancel“ : { „href“ : … }, … „createdDate“ : …, „status“ : „Payment expected“ … }
72. 66 “Internationalize
 all user facing text.
73. Aaaargh! 67
74. Option 2:
 Inspecting
 hypermedia elements 68
75. 69 GET /order/42 { „_links“ : { „cancel“ : { „href“ : … }, … „createdDate“ : …, „status“ : „Payment expected“ … }
76. Reducing decisions in clients to whether a
 link is present or not. 70
77. Trading domain knowledge with protocol complexity in clients. 71
78. 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
79. API evolvability is key
 in a system of systems 73 See „Evolving Distributed Systems“
80. Translate backend concepts into web- appropriate ones. 74
81. 75 Aggregate Root / Repository Collection / Item Resources IDs URIs @Version ETags Last Modified Property Last Modified Header Relations Links
82. RESTBucks payment expected preparing cancelled ready completed 1 2 3 4 5 6
83. 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
84. 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
85. Spring RESTBucks 79
86. Web Service Repository - Orders Spring Data Spring Data
 REST Payment Spring Data Manual
 implementation Manual
 implementation
87. Resources 81 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/
88. Questions? 82