DDD & REST — Domain-Driven APIs for the web

Slides of the talk I gave at SpringOne Platform, Las Vegas

Transcript

1. Unless otherwise indicated, these slides are © 2013-2016 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ DDD & REST
 Domain-Driven APIs for the web Oliver Gierke / olivergierke ogierke@pivotal.io
3. Background 3
4. 4 Spring Data Repositories &
 Aggregates Spring HATEOAS Hypermedia
 for Spring MVC Spring Data REST
5. When designing REST APIs, what can we learn from DDD? “ 5
6. What does it take to bridge the worlds of DDD & REST? “ 6
8. 8 http://www.infoq.com/minibooks/domain-driven-design-quickly
11. Implementing Domain-Driven Design 10
12. Value objects 11
13. Stringly typed code 12 public class Customer { private Long id; private String firstname, lastname, email; … }
14. Stringly typed code 13 public class SomeService { public void createUser(String firstname,
 String lastname, String email) { … } }
15. 14 public class Customer { private Long id; private Firstname firstname; private Lastname lastname; private EmailAddress emailAddress; … }
16. Value Objects are a
 PITA to build in
 some languages. 15
17. Still, they’re worth it. 16 See „Power Use of Value Objects in DDD“ by Dan Bergh Johnsson.
18. Lombok — putting the spice back into Java. 17
19. 18 @Value public class Customer { UUID id = UUID.randomUUID(); Firstname firstname; Lastname lastname; EmailAddress email; @Value static class EmailAddress { String value; } }
20. AutoValue 19 Project website on GitHub.
21. Entities & Repositories 20
22. 21 Order LineItem Product Invoice Customer Payment Address Email
23. 21 Order LineItem Product Invoice Customer Payment Address Email
24. Entity +
 Repository = 
 Aggregate 22
25. Aggregates.
 Scopes of consistency. 23
26. 24 Order LineItem Product Invoice Customer Payment Address Email
27. Aggregates.
 The key things
 to refer to. 25
28. 26 Order LineItem Product Invoice Customer Payment Address Email
29. Don’t get trapped by datastore thinking. 27
30. 28 Order LineItem Product Invoice Customer Payment Address Email
31. Bounded Context 29
32. Order LineItem Product Invoice Customer Payment Address
33. 31 Shipping Accounting Catalog Orders User
 Registration
34. 31 Shipping Accounting Catalog Orders User
 Registration Accounting Payment information Billing Address Shipping Shipping address Customer Product
35. Domain Events 32
36. 33 Level 0: No events at all
37. 33 Level 0: No events at all Level 1: Explicit operations
38. If you’re calling two setters in a row, you’re missing a concept. 34
39. 35 Level 0: No events at all Level 1: Explicit operations Level 2: Some operations as events
40. Domain events as
 state transitions. 36
41. Expose important
 events to interested parties via feeds. 37
42. 38 Level 0: No events at all Level 1: Explicit operations Level 2: Some operations as events Level 3: Event Sourcing
43. REST 39
44. REST ≠ 
 CRUD via HTTP 40
45. Representation design matters 41
46. Value objects
 need custom 
 serializers. 42
47. Aggregates Identifiable
 Referable
 Scope of consistency 43
48. Resources Identifiable
 Referable
 Scope of consistency 44
49. Hypermedia 45
50. Serving data and navigation information
 at the same time. 46
51. Trading domain knowledge with protocol complexity in clients. 47
52. 48 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
53. API evolvability is key
 in a system of systems 49
54. 50 GET /orders { „_links“ : { „cancel“ : { „href“ : … }, … „createdDate“ : …, „status“ : „Payment expected“ … }
55. 51 GET /orders { „_links“ : { „cancel“ : { „href“ : … }, … „createdDate“ : …, „status“ : „Payment expected“ … }
56. 52 “Internationalize
 all user facing text.
57. Aaaargh! 53
58. 54 GET /orders { „_links“ : { „cancel“ : { „href“ : … }, … „createdDate“ : …, „status“ : „Payment expected“ … }
59. Reducing decisions in clients to whether a
 link is present or not. 55
60. Prefer explicit 
 state transitions over poking at your resources using PATCH. 56
61. Translate domain concepts into web- appropriate ones. 57
62. 58 Aggregate Root / Repository Collection / Item Resources IDs URIs @Version ETags Last Modified Property Last Modified Header Relations Links
63. RESTBucks payment expected preparing cancelled ready completed 1 2 3 4 5 6
64. 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
65. 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
66. Spring RESTBucks 62
67. Web Service Repository - Orders Spring Data Spring Data
 REST Payment Spring Data Manual
 implementation Manual
 implementation
68. JacksonCustomizations Externalize tweaks to the general JSON design 64
69. Spring Data REST
 for the CRUDdy parts. 65
70. ResourceProcessor To conditionally sneak links into the default representation. 66
71. Resources 67 Spring RESTBucks
 https://github.com/olivergierke/spring-restbucks Benefits of Hypermedia APIs
 http://olivergierke.de/2016/04/benefits-of-hypermedia/index.html
72. Questions? 68