DDD & REST — Domain-Driven APIs for the web

Slides of the talk on the connection between Domain-Driven Design and REST I held at GOTO conference, Berlin.

@springcentral

Transcript

1. DDD & REST Domain-Driven APIs for the web / olivergierke Oliver Gierke
3. Background 3
4. 4 Spring Data Repositories &
 Aggregates Spring HATEOAS Hypermedia
 for Spring MVC Spring Data REST
5. REST ≠ 
 CRUD via HTTP 5
6. What does it take to bridge the worlds of DDD & REST? “
9. Value objects 8
10. Value Objects are a
 PITA to build in
 some languages. 9
11. Still, they’re worth it. 10 See „Power Use of Value Objects in DDD“ by Dan Bergh Johnsson.
12. Lombok — putting the spice back into Java. 11
13. Key opponents: Mapping libraries
 that need to
 (de)serialize them. 12
14. Entities & Repositories 13
16. 14 Customer Payment Address Email
17. 14 Invoice Customer Payment Address Email
18. 14 Order LineItem Invoice Customer Payment Address Email
19. 14 Order LineItem Product Invoice Customer Payment Address Email
20. 14 Order LineItem Product Invoice Customer Payment Address Email
21. Entity +
 Repository = 
 Aggregate 15
22. Aggregates form nice representation boundaries. 16
23. Aggregates become
 the key things
 to refer to. 17
24. Don’t get trapped by datastore thinking. 18
25. Try to avoid 
 bi-directional relationships. 19
26. Domain Events 20
27. 21 Level 0: No events at all
28. 21 Level 0: No events at all Level 1: Explicit operations
29. If you’re calling two setters in a row, you’re missing a concept. 22
30. 23 Level 0: No events at all Level 1: Explicit operations Level 2: Some operations as events
31. Domain events as
 state transitions. 24
32. Expose important
 events to interested parties via feeds. 25
33. 26 Level 0: No events at all Level 1: Explicit operations Level 2: Some operations as events Level 3: Event Sourcing
34. REST 27
35. Representation design matters 28
36. Aggregates Identifiable
 Referable
 Scope of consistency 29
37. Resources Identifiable
 Referable
 Scope of consistency 30
38. Hypermedia 31
39. Serving data and navigation information
 at the same time. 32
40. Trading domain knowledge with protocol complexity in clients. 33
41. Reducing decisions in clients to whether a
 link is present or not. 34
42. Prefer explicit 
 state transitions over poking at your resources using PATCH. 35
43. Translate domain concepts into web- appropriate ones. 36
44. 37 Aggregate Root / Repository Collection / Item Resources IDs URIs @Version ETags Last Modified Property Last Modified Header Relations Links
45. RESTBucks
46. RESTBucks payment expected preparing cancelled ready completed 1 2 3 4 5 6
47. 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
48. 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
49. Spring RESTBucks 41
50. Web Service Repository - Orders Spring Data Spring Data
 REST Payment Spring Data Manual
 implementation Manual
 implementation
51. JacksonCustomizations Externalize tweaks to the general JSON design 43
52. Spring Data REST
 for the CRUDdy parts. 44
53. ResourceProcessor To conditionally sneak links into the default representation. 45
54. Code 46 Spring RESTBucks - https://github.com/olivergierke/spring-restbucks
55. Questions? 47