Fundamental Domain-Driven Design For Microservices

Slides of the talk I gave at JAX 2016, Mayence.

@springcentral

Transcript

1. © 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission. DOMAIN-DRIVEN DESIGN / OLIVERGIERKE ƻ OGIERKE@PIVOTAL.IO GRUNDLEGENDES FÜR MICROSERVICES
4. 4 http://www.infoq.com/minibooks/domain-driven-design-quickly
5. Microservices ♥
 Domain-Driven Design 5 Slides and video by Michael Plöd.
8. Implementing Domain-Driven Design 7
9. Value objects 8
10. Stringly typed code 9 public class Customer { private Long id; private String firstname, lastname, email; … }
11. Stringly typed code 10 public class SomeService { public void createUser(String firstname,
 String lastname, String email) { … } }
12. 11 public class Customer { private Long id; private Firstname firstname; private Lastname lastname; private EmailAddress emailAddress; … }
13. Value Objects are a
 PITA to build in
 some languages. 12
14. Still, they’re worth it. 13 See „Power Use of Value Objects in DDD“ by Dan Bergh Johnsson.
15. Lombok — putting the spice back into Java. 14
16. 15 @Value public class Customer { UUID id = UUID.randomUUID(); Firstname firstname; Lastname lastname; EmailAddress email; @Value static class EmailAddress { String value; } }
17. AutoValue 16 Project website on GitHub.
18. Key opponents: Mapping libraries
 that need to
 (de)serialize them. 17
19. Entities & Aggregates 18
20. Persistence technology
 VS.
 Domain model 19
21. Challenges with JPA:
 
 Value objects as @Entity
 Flat relationships 20
22. 21 Order LineItem Product Invoice Customer Payment Address Email
23. 21 Order LineItem Product Invoice Customer Payment Address Email
24. Repositories turn
 an entity into an aggregate root. 22
25. 23 Order LineItem Product Invoice Customer Payment Address Email
26. Bounded Context 24
27. Order LineItem Product Invoice Customer Payment Address
28. 26 Shipping Accounting Catalog Orders User
 Registration
29. 26 Shipping Accounting Catalog Orders User
 Registration Accounting Payment information Billing Address Shipping Shipping address Customer
30. 26 Shipping Accounting Catalog Orders User
 Registration Accounting Payment information Billing Address Shipping Shipping address Customer Product
31. Domain-Driven Design & Monoliths 27
32. Avoid technologies that get in your way. 28
33. How to enforce
 context boundaries? 29
34. What about
 consistency? 30
35. References between Bounded Contexts? 31
36. Domain Events 32
37. 33 Level 0: No events at all
38. 33 Level 0: No events at all Level 1: Explicit operations
39. If you’re calling two setters in a row, you’re missing a concept. 34
40. 35 Level 0: No events at all Level 1: Explicit operations
41. 35 Level 0: No events at all Level 1: Explicit operations Level 2: Some operations as events
42. State transitions
 become domain
 events. 36
43. 37 Level 0: No events at all Level 1: Explicit operations Level 2: Some operations as events
44. 37 Level 0: No events at all Level 1: Explicit operations Level 2: Some operations as events Level 3: Event Sourcing
45. Domain-Driven Design & Microservices 38
46. Bounded contexts 
 define system
 boundaries. 39
47. 40 Shipping Accounting Catalog Orders User
 Registration Accounting Payment information Billing Address Shipping Shipping address Customer Product
48. 41 Shipping Accounting Catalog Orders User
 Registration Accounting Shipping
49. 42 Shipping Accounting Catalog Orders User
 Registration Accounting Shipping HTTP Messaging
50. Architecture is less
 likely to deteriorate
 as it’s harder to
 violate boundaries. 43
51. Restructuring
 service boundaries
 is much harder. 44
52. Inter-Service communication
 becomes remote
 communication. 45
53. Accept and embrace eventual consistency between services. 46
54. Domain Events 47
55. REST & Messaging 48
56. Domain events
 become state
 transitions. 49
57. Hypermedia for state transition and explicit events. 50
58. Thanks! 51