Implementing DDD with the Spring ecosystem

Domain-Driven Design is currently a very popular way of implementing and looking at Microservices. This session aims at giving you a kickstart how to work on the implementation details of DDD in the Spring Ecosystem. We will take a look at how to model your microservices with Bounded Contexts and Strategic Design, after that we will dive into a Microservice and look at how to implement Aggregates, Repositories and how to work with Domain Events. All the implementation details will leverage various Spring technologies such as Spring Boot, -Data and -Cloud. This talk consists of a bit of theroy and a lot of code.

Transcript

1. Michael Plöd, @bitboss
   Implementing
   with the Spring ecosystem
   DDD
   

   View Slide

2. Disclaimer
   Michael Plöd - innoQ

   @bitboss
   Most of these ideas do not come
   from me personally. I have to
   thank Eric Evans and Vaughn
   Vernon for all the inspiration and
   ideas. If you haven’t: go out and
   get their amazing books!
   

   View Slide

3. Feel free to replace developer by architect, team lead, team
   member or domain expert.
   Nothing in this talk is a silver bullet.
   

   View Slide

4. Bounded Context
   Spring
   Spring
   Core
   Spring
   Boot
   Spring
   Data
   Spring
   Cloud
   Spring
   MVC
   Spring
   Events
   Good
   OO 

   practice
   Aggregates
   Entities
   Value Objects
   Factories
   Services
   Repositories
   TOPICS
   I will talk about today
   

   View Slide

5. Model your
   Microservices along
   business capabilities
   

   View Slide

6. Bounded Context
   Context Map
   Shared Kernel
   Customer /
   

   Supplier
   Conformist
   Anticorruption

   Layer
   Separate W
   ays
   Open / Host 

   Service
   Published
   

   Language
   STRATEGIC DESIGN
   helps us with regards to
   business capabilities
   

   View Slide

7. Bounded Context
   Every sophisticated business
   (sub-) domain consists of a
   bunch of Bounded Contexts
   Each Bounded Context
   contains a domain model,
   don’t nest Bounded Contexts
   The Bounded Context is
   also a boundary for the
   meaning of a given model
   

   View Slide

8. Example - You at spring.io
   Reservations
   Event

   Management
   Badges
   spring.io

   Visitor
   Name
   Payment Details
   Address
   Company
   Session Registrations
   Lunch Preferences
   Name
   Job Description
   Twitter Handle
   

   View Slide

9. A Bounded Context is the 

   BOUNDARY
   

   for the meaning of a model
   

   View Slide

10. Don’t
    Repeat
    Yourself
    INSIDE
    of a
    Bounded
    Context
    

    View Slide

11. Repeat
    Yourself
    BETWEEN
    several
    Bounded
    Contexts
    

    View Slide

12. Microservice architectures
    should be evolvable
    

    View Slide

13. Aggregates
    (Internal) 

    Building Blocks
    Entities
    Value Objects
    Factories
    Services
    Repositories
    TACTICAL
    DESIGN
    helps us with regards to
    evolvability of
    microservices
    

    View Slide

14. Building

    Blocks
    Entities
    Entities represent the core
    business objects of a
    bounded context’s model
    Each Entity has a
    constant identity
    Each Entity has its own
    lifecycle
    Customer
    Credit
    Application
    Shipment
    

    View Slide

15. Building

    Blocks
    Value Objects
    Value Objects derive their
    identity from their values
    Value Objects do not have
    their own lifecycle, they
    inherit it from Entities
    that are referencing them
    You should always
    consider value objects for
    your domain model
    Color
    Monetary
    Amount
    Customer
    

    View Slide

16. Building

    Blocks
    Is „Customer“ an Entity or 

    a Value Object
    If an object can be considered an
    Entity or a Value Object always
    depends on the (Bounded Context)
    it resides in.
    Customer Example: A customer is an entity in
    a CRM-like microservice but not in
    a microservice that prints badges,
    there we are just interested in
    name, job description and Twitter
    handle
    

    View Slide

17. Your DDD Entity is
    NOT
    your JPA Entity
    

    View Slide

18. Building

    Blocks
    Aggregates
    Do not
    underestimate
    the power of
    the Aggregate
    

    View Slide

19. Building

    Blocks
    Aggregates
    
    SelfDisclosure
    
    Address
    
    RedemptionDetail
    
    Loan
    
    Customer
    
    LoanApplicationForm
    
    Aggregates group Entities. The Root Entity is the lead in
    terms of access to the object graph and lifecycle.
    

    View Slide

20. Best Practices for Aggregates
    Hints
    Small
    Prefer small aggregates that usually only contain
    an Entity and some Value Objects.
    Consistency
    Boundaries
    Take a look which parts of your model must be
    updated in an atomically consistent manner
    One TX per
    Aggregate
    Aggregates should be updated in separate
    transations which leads to eventual consistency
    Reference by
    Identity
    Do not implement direct references to other Root
    Entities. Prefer referencing to Identity Value
    Objects
    

    View Slide

21. Implementing
    Aggregates
    

    View Slide

22. Building

    Blocks
    Aggregate Example
    Battery of an electric car
    Battery Cells
    Status
    Charger
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    General Information
    

    View Slide

23. Building

    Blocks
    Aggregate Example
    Battery of an electric car
    Think about good a good old OO practice:
    information hiding
    Personal opionion: In the advent of POJOs
    we have unlearned information hiding
    A blind „Genereate Getters and Setters“ in
    your IDE is your enemy
    Battery Cells
    Status
    Charger
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    General Information
    

    View Slide

24. Building

    Blocks
    Aggregate Example
    Battery of an electric car
    Do we need an external access to the
    cells?
    Stuff we want to do from the outside:
    - Start charging
    - Get current charge level
    - Get information about the charging
    Battery Cells
    Status
    Charger
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    Cell
    General Information
    

    View Slide

25. View Slide

26. Hints
    Visibility
    Use the power of your programming language, private
    Attributes with public getters and setters are no
    information hiding. Yes, you can have classes with a
    package visibility level.
    Packages
    Place each aggregate in its own package and work with
    package level visibility
    References
    I prefer Aggregates that do not reference themselves,
    they are hooked together with a few shared value
    objects which leads to more decoupling
    

    View Slide

27. Applicant
    Address
    Account

    Balance
    Scoring

    Result
    Scoring
    Calculations
    Score Color
    AgencyResult
    KoCriteria
    Warning

    Message
    Financial

    Situation
    Incomings Outgoings
    PersonId Application

    Number
    

    View Slide

28. Root Entity directly Explicit Aggregate Class
    Implementation Options
    Aggregates
    

    View Slide

29. Keep your
    Aggregates
    Spring free
    

    View Slide

30. Adapter
    Adapter
    Adapter
    Adapter
    Adapter
    Adapter
    Adapter
    Adapter
    Web
    Mobile
    Cloud
    Messaging
    Database
    Document
    GraphDB
    Messaging
    Core

    

    

    

    Domain
    

    View Slide

31. The hexagonal architecture is not your only
    option and is not suitable for everything
    „The domain should be the heart of a system“
    Hexagonal
    ➡ For bounded contexts
    with a lot of logic and
    calculations
    ➡ Complex
    ➡ Many mappings
    ➡ Good fit for the DDD
    internal building blocks
    CRUD
    ➡ For bounded contexts
    that just store and read
    data
    ➡ Keep it simple
    ➡ Spring Data Rest may
    be your friend
    Query Driven
    ➡ For bounded contexts
    that perform complex
    queries
    ➡ Mostly based on a read
    model
    ➡ Sometimes the „Q“ in
    distributed CQRS
    

    View Slide

32. Communication between
    Bounded Contexts
    

    View Slide

33. Orchestration
    vs
    Choreography
    Building Microservices by Sam Newman, O'Reilly
    Event
    Stream
    Choreography
    Orchestration
    

    View Slide

34. Choreography
    Credit

    Application
    Scoring
    Credit
    Decision
    Customer
    Credit

    Application

    Submitted
    Event
    

    View Slide

35. Credit

    Application

    Submitted
    Event
    We can use Domain
    Events for the
    communication between
    Bounded Contexts.
    This leads us to
    Event-driven Applications
    

    View Slide

36. !
    Model information about
    activity in the domain as a
    series of discrete events.
    

    View Slide

37. An event is something 

    that happened in the past
    t
    now
    Event
    Event
    Event
    Event
    Event
    

    View Slide

38. Options for Event Payload
    Options
    Full Payload The event carries complete Entitiy-Graphs or
    Aggregates
    Mix
    The event contains data that is usually of interest to
    many other contexts. For special purposes there is also
    a URL to a RESTful HTTP Ressource
    Empty The event is empty or contains only minimal data and
    is being used to trigger pulling from a feed (eg. Atom)
    REST URL The event only carries a URL to a RESTful HTTP
    Ressource
    

    View Slide

39. View Slide

40. Spring
    Cloud Stream
    Broker
    Very often the de-facto choice for many distributed
    systems. Typical choices nowadays would be Apache
    Kafka or RabbitMQ. High degree of decoupling.
    Internal 

    Event Bus
    Only JVM internal with synchronous and / or
    asynchronous options. Highly recommended for
    building decoupled monoliths.
    HTTP Feeds
    REST + Events = Feeds

    

    Often ignored option in which you won’t need a
    dedicated broker.
    Spring MVC
    + Quartz 

    + Rome
    Spring
    Application
    Events
    

    View Slide

41. Very useful!
    

    View Slide

42. I’m writing a book
    

    View Slide

43. Implementing
    with the Spring ecosystem
    Michael Plöd

    @bitboss
    https://github.com/mploed

    https://speakerdeck.com/mploed

    https://leanpub.com/ddd-by-example
    DDD
    

    View Slide