Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Implementing DDD with the Spring ecosystem

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.

Michael Plöd

May 24, 2018
Tweet

More Decks by Michael Plöd

Other Decks in Programming

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