Fundamental Domain-Driven Design For Microservices

Slides of the talk I gave at Java Forum Stuttgart 2016.

#jfs2016 @springcentral

Transcript

1. © 2014 SpringOne 2GX. All rights reserved. Do not distribute without permission. DOMAIN-DRIVEN DESIGN / OLIVERGIERKE ƻ OGIERKE@PIVOTAL.IO FUNDAMENTAL FOR MICROSERVICES
4. 4 http://www.infoq.com/minibooks/domain-driven-design-quickly
5. Microservices ♥
 Domain-Driven Design 5 11:10 — Beethoven Saal
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. Entities & Aggregates 17
19. 18 Order LineItem Product Invoice Customer Payment Address Email
20. 18 Order LineItem Product Invoice Customer Payment Address Email
21. Persistence technology
 VS.
 Domain model 19
22. Aggregate =
 Entity + Repository 20
23. 21 Order LineItem Product Invoice Customer Payment Address Email
24. Bounded Context 22
25. Order LineItem Product Invoice Customer Payment Address
26. 24 Shipping Accounting Catalog Orders User
 Registration
27. 24 Shipping Accounting Catalog Orders User
 Registration Accounting Payment information Billing Address Shipping Shipping address Customer Product
28. Domain-Driven Design & Monoliths 25
29. Avoid technologies that get in your way. 26
30. How to enforce
 context boundaries? 27
31. What about
 consistency? 28
32. References between Bounded Contexts? 29
33. Domain Events 30
34. 31 Level 0: No events at all
35. 31 Level 0: No events at all Level 1: Explicit operations
36. If you’re calling two setters in a row, you’re missing a concept. 32
37. 33 Level 0: No events at all Level 1: Explicit operations Level 2: Some operations as events
38. State transitions
 become domain
 events. 34
39. 35 Level 0: No events at all Level 1: Explicit operations Level 2: Some operations as events Level 3: Event Sourcing
40. Domain-Driven Design & Microservices 36
41. Bounded contexts 
 define system
 boundaries. 37
42. 38 Shipping Accounting Catalog Orders User
 Registration Accounting Payment information Billing Address Shipping Shipping address Customer Product
43. 39 Shipping Accounting Catalog Orders User
 Registration Accounting Shipping
44. 40 Shipping Accounting Catalog Orders User
 Registration Accounting Shipping HTTP Messaging
45. Architecture is less
 likely to deteriorate
 as it’s harder to
 violate boundaries. 41
46. Restructuring
 service boundaries
 is much harder. 42
47. Inter-Service communication
 becomes remote
 communication. 43
48. Accept and embrace eventual consistency between services. 44
49. Domain Events 45
50. REST & Messaging 46
51. Domain events
 become state
 transitions. 47
52. Hypermedia for state transition and explicit events. 48
53. Thanks! 49