Slide 1

Slide 1 text

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 [email protected]

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

Background 3

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

9

Slide 10

Slide 10 text

9

Slide 11

Slide 11 text

Implementing Domain-Driven Design 10

Slide 12

Slide 12 text

Value objects 11

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

14 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. 15

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Lombok — putting the spice back into Java. 17

Slide 19

Slide 19 text

18 @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

AutoValue 19 Project website on GitHub.

Slide 21

Slide 21 text

Entities & Repositories 20

Slide 22

Slide 22 text

21 Order LineItem Product Invoice Customer Payment Address Email

Slide 23

Slide 23 text

21 Order LineItem Product Invoice Customer Payment Address Email

Slide 24

Slide 24 text

Entity +
 Repository = 
 Aggregate 22

Slide 25

Slide 25 text

Aggregates.
 Scopes of consistency. 23

Slide 26

Slide 26 text

24 Order LineItem Product Invoice Customer Payment Address Email

Slide 27

Slide 27 text

Aggregates.
 The key things
 to refer to. 25

Slide 28

Slide 28 text

26 Order LineItem Product Invoice Customer Payment Address Email

Slide 29

Slide 29 text

Don’t get trapped by datastore thinking. 27

Slide 30

Slide 30 text

28 Order LineItem Product Invoice Customer Payment Address Email

Slide 31

Slide 31 text

Bounded Context 29

Slide 32

Slide 32 text

Order LineItem Product Invoice Customer Payment Address

Slide 33

Slide 33 text

31 Shipping Accounting Catalog Orders User
 Registration

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Domain Events 32

Slide 36

Slide 36 text

33 Level 0: No events at all

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Domain events as
 state transitions. 36

Slide 41

Slide 41 text

Expose important
 events to interested parties via feeds. 37

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

REST 39

Slide 44

Slide 44 text

REST ≠ 
 CRUD via HTTP 40

Slide 45

Slide 45 text

Representation design matters 41

Slide 46

Slide 46 text

Value objects
 need custom 
 serializers. 42

Slide 47

Slide 47 text

Aggregates Identifiable
 Referable
 Scope of consistency 43

Slide 48

Slide 48 text

Resources Identifiable
 Referable
 Scope of consistency 44

Slide 49

Slide 49 text

Hypermedia 45

Slide 50

Slide 50 text

Serving data and navigation information
 at the same time. 46

Slide 51

Slide 51 text

Trading domain knowledge with protocol complexity in clients. 47

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

API evolvability is key
 in a system of systems 49

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

52 “Internationalize
 all user facing text.

Slide 57

Slide 57 text

Aaaargh! 53

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

Translate domain concepts into web- appropriate ones. 57

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 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 65

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

Slide 66 text

Spring RESTBucks 62

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

JacksonCustomizations Externalize tweaks to the general JSON design 64

Slide 69

Slide 69 text

Spring Data REST
 for the CRUDdy parts. 65

Slide 70

Slide 70 text

ResourceProcessor To conditionally sneak links into the default representation. 66

Slide 71

Slide 71 text

Resources 67 Spring RESTBucks
 https://github.com/olivergierke/spring-restbucks Benefits of Hypermedia APIs
 http://olivergierke.de/2016/04/benefits-of-hypermedia/index.html

Slide 72

Slide 72 text

Questions? 68