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

3

Slide 4

Slide 4 text

Background 4

Slide 5

Slide 5 text

5 Spring Data Repositories &
 Aggregates Spring HATEOAS Hypermedia
 for Spring MVC Spring Data REST

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

10

Slide 11

Slide 11 text

Implementing Domain-Driven Design 11

Slide 12

Slide 12 text

Value objects 12

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Stringly typed code 14 public class SomeService { public void createUser(String firstname,
 String lastname, String email) { … } }

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Value Objects are a
 PITA to build in
 some languages. 16

Slide 17

Slide 17 text

Still, they’re worth it. 17 See „Power Use of Value Objects in DDD“ by Dan Bergh Johnsson.

Slide 18

Slide 18 text

Lombok — putting the spice back into Java. 18

Slide 19

Slide 19 text

19 @Value public class Customer { UUID id = UUID.randomUUID(); Firstname firstname; Lastname lastname; EmailAddress email; @Value static class EmailAddress { String value; } }

Slide 20

Slide 20 text

Entities & Repositories 21

Slide 21

Slide 21 text

22 Order LineItem Product Invoice Customer Payment Address Email

Slide 22

Slide 22 text

22 Order LineItem Product Invoice Customer Payment Address Email

Slide 23

Slide 23 text

Don’t get trapped by datastore thinking. 23

Slide 24

Slide 24 text

24 Order LineItem Product Invoice Customer Payment Address Email

Slide 25

Slide 25 text

Entity +
 Repository = 
 Aggregate 25

Slide 26

Slide 26 text

Aggregates.
 Scopes of consistency. 26

Slide 27

Slide 27 text

27 Order LineItem Product Invoice Customer Payment Address Email

Slide 28

Slide 28 text

Aggregates.
 The key things
 to refer to. 28

Slide 29

Slide 29 text

29 Order LineItem Product Invoice Customer Payment Address Email

Slide 30

Slide 30 text

Bounded Context 30

Slide 31

Slide 31 text

Order LineItem Product Invoice Customer Payment Address

Slide 32

Slide 32 text

32 Shipping Accounting Catalog Orders User
 Registration

Slide 33

Slide 33 text

32 Shipping Accounting Catalog Orders User
 Registration Accounting Payment information Billing Address Shipping Shipping address Customer Product

Slide 34

Slide 34 text

Domain Events 33

Slide 35

Slide 35 text

34 Level 0: No events at all

Slide 36

Slide 36 text

34 Level 0: No events at all Level 1: Explicit operations

Slide 37

Slide 37 text

If you’re calling two setters in a row, you’re missing a concept. 35

Slide 38

Slide 38 text

36 Level 0: No events at all Level 1: Explicit operations Level 2: Some operations as events

Slide 39

Slide 39 text

Domain events as
 state transitions. 37

Slide 40

Slide 40 text

Expose important
 events to interested parties via feeds. 38

Slide 41

Slide 41 text

39 Level 0: No events at all Level 1: Explicit operations Level 2: Some operations as events Level 3: Event Sourcing

Slide 42

Slide 42 text

REST 40

Slide 43

Slide 43 text

REST ≠ 
 CRUD via HTTP 41

Slide 44

Slide 44 text

Representation design matters 42

Slide 45

Slide 45 text

Value objects
 need custom 
 serializers. 43

Slide 46

Slide 46 text

Aggregates Identifiable
 Referable
 Scope of consistency 44

Slide 47

Slide 47 text

Resources Identifiable
 Referable
 Scope of consistency 45

Slide 48

Slide 48 text

Hypermedia 46

Slide 49

Slide 49 text

Serving data and navigation information
 at the same time. 47

Slide 50

Slide 50 text

Trading domain knowledge with protocol complexity in clients. 48

Slide 51

Slide 51 text

49 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 52

Slide 52 text

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

Slide 53

Slide 53 text

51 GET /orders { „_links“ : { „cancel“ : { „href“ : … }, … „createdDate“ : …, „status“ : „Payment expected“ … }

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

Option 1:
 Inspecting the payload 53

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

55 “Internationalize
 all user facing text.

Slide 58

Slide 58 text

Aaaargh! 56

Slide 59

Slide 59 text

Option 2:
 Inspecting
 hypermedia elements 57

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

Prefer explicit 
 state transitions over poking at your resources using PATCH. 60

Slide 63

Slide 63 text

Translate backend concepts into web- appropriate ones. 61

Slide 64

Slide 64 text

62 Aggregate Root / Repository Collection / Item Resources IDs URIs @Version ETags Last Modified Property Last Modified Header Relations Links

Slide 65

Slide 65 text

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

Slide 66

Slide 66 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 67

Slide 67 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 68

Slide 68 text

Spring RESTBucks 66

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

Resources 68 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 71

Slide 71 text

Questions? 69