The revival of Domain-Driven Design in the context of microservices

The revival of Domain-Driven Design in the context of microservices

Slides of the talk I gave at JPMC Tech Symposium, Glasgow. http://pivotal.io/event/jpmc-glasgow-tech-symposium

@springcentral

977c74bb044a9d4fa90b305824eda390?s=128

Oliver Drotbohm

March 11, 2016
Tweet

Transcript

  1. © 2014 SpringOne 2GX. All rights reserved. Do not distribute

    without permission. DOMAIN-DRIVEN DESIGN / OLIVERGIERKE ƻ OGIERKE@PIVOTAL.IO THE REVIVAL OF IN THE CONTEXT OF MICROSERVICES
  2. 2

  3. None
  4. 4 http://www.infoq.com/minibooks/domain-driven-design-quickly

  5. 5

  6. 5

  7. Implementing Domain-Driven Design 6

  8. Value objects 7

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

    8
  10. Still, they’re worth it. 9 See „Power Use of Value

    Objects in DDD“ by Dan Bergh Johnsson.
  11. Lombok — putting the spice back into Java. 10

  12. 11 @Value public class Customer { UUID id = UUID.randomUUID();

    String firstname, lastname; EmailAddress email; @Value static class EmailAddress { String value; } }
  13. Key opponents: Mapping libraries
 that need to
 (de)serialize them. 12

  14. Spring Data REST 13 Support for lookup types — Ticket

    in JIRA
  15. Entities & Aggregates 14

  16. Persistence technology
 VS.
 Domain model 15

  17. 16 Order LineItem Product Invoice Customer Payment Address Email

  18. 16 Order LineItem Product Invoice Customer Payment Address Email

  19. Repositories turn
 an entity into an aggregate root. 17

  20. Domain-Driven Design & Monoliths 18

  21. Bounded Context 19

  22. Order LineItem Product Invoice Customer Payment Address

  23. 21 Shipping Accounting Catalog Orders User
 Registration

  24. 21 Shipping Accounting Catalog Orders User
 Registration Accounting Payment information

    Billing Address Shipping Shipping address Customer
  25. 21 Shipping Accounting Catalog Orders User
 Registration Accounting Payment information

    Billing Address Shipping Shipping address Customer Product
  26. How to enforce
 context boundaries? 22

  27. Domain-Driven Design & Microservices 23

  28. Bounded contexts 
 define system
 boundaries. 24

  29. 25 Shipping Accounting Catalog Orders User
 Registration Accounting Payment information

    Billing Address Shipping Shipping address Customer Product
  30. 26 Shipping Accounting Catalog Orders User
 Registration Accounting Shipping

  31. Architecture is less
 likely to deteriorate
 as it’s harder to


    violate boundaries. 27
  32. Restructuring
 service boundaries
 is much harder. 28

  33. Simon Brown — Blog post "If you can't build a

    monolith, what makes
 you think microservices
 are the answer?
  34. "I’m firmly convinced that starting with a monolith is usually

    exactly the wrong thing to do. Stefan Tilkov — Blog post
  35. Don’t start with a Monolith. Don’t over-divide, either. If in

    doubt, keep stuff together
 and split up later. 31
  36. Self-Contained Systems 32 See www.scs-architecture.org

  37. Microservices calling Microservices calling Microservices calling… 33

  38. RxJava, Hystrix, Zipkin
 et al. to the rescue!
 — aka

    —
 Solving the problem
 at runtime. 34
  39. "If you have to call other services in order to

    be able to serve a response to a request from a public client, this is really an architectural problem. Daniel Westheide — Blog post
  40. Still, you expose (more) API that needs to be maintained

    and
 evolved properly. 36
  41. REST VS. Messaging 37

  42. REST 38

  43. More coupling on the protocol level, but dedicated means to

    evolve APIs. 39
  44. Messaging 40

  45. Less coupling on the protocol level, less predefined semantics and

    means to evolve. 41
  46. Domain-Driven Design & REST 42

  47. Identification and addressability 43

  48. Aggregates Identifiable
 Referable
 Scope of consistency 44

  49. Resources Identifiable
 Referable
 Scope of consistency 45

  50. Everything that can
 be linked to can easily
 be integrated

    into
 your system. 46
  51. Accept and embrace eventual consistency between services. 47

  52. If that’s an issue, the service boundaries are probably wrong.

    48
  53. Hypermedia for state transition and explicit events. 49

  54. Event Feeds 50

  55. Services publish (Atom) feeds containing events.
 Clients subscribe to 


    those and consume 
 them as needed. 51
  56. Thanks! 52