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

Microservices love Domain Driven Design, why and how?

Microservices love Domain Driven Design, why and how?

Without any doubt Eric Evans' book "Domain Driven Design" is being considered as a "must have read" among many IT specialists from various domains. With the emergence of Microservices Domain Driven Design has become more relevant then ever. This talk explains how the patterns and concepts of Domain Driven Design relate to Microservice architectures. In addition to that I will show off how Domain Driven Design will help you to structure and model your Microservices in terms of granularity, business context and interface design (just to name a few).

Michael Plöd

May 09, 2017
Tweet

More Decks by Michael Plöd

Other Decks in Programming

Transcript

  1. Microservices
    <3
    Domain Driven Design
    Michael Plöd - innoQ

    @bitboss

    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 / ideas. If you haven’t: go
    out and get their amazing books!

    View Slide

  3. D D D
    in Microservices
    DDD and Microservices
    are not just about
    Bounded Contexts
    DDD itself is not just
    about Aggregates, Entities
    and Services

    View Slide

  4. Domain Driven Design
    helps us with

    Microservices in four
    areas
    Strategic Design
    (Internal) 

    Building Blocks
    Large Scale

    Structure
    Destillation

    View Slide

  5. Strategic Design
    Strategic Design
    consists of
    Bounded Context
    Context Map
    Shared
    Kernel
    Customer
    / 

    Supplier
    Conformist
    Anticorruption

    Layer
    Separate
    Ways
    Open
    /
    Host 

    Service
    Published 

    Language

    View Slide

  6. Strategic

    Design
    Bounded Context
    Every sophisticated business
    domain consists of a bunch 

    of Bounded Contexts
    Each Bounded Context
    contains models and maybe
    other contexts
    The Bounded Context is also
    a boundary for the meaning
    of a given model

    View Slide

  7. Strategic

    Design
    Bounded Context Example
    Reservations
    Event

    Management
    Badges
    Customer
    Name
    Payment Details
    Address
    Company
    Session Registrations
    Lunch Preferences
    Name
    Job Description
    Twitter Handle

    View Slide

  8. Strategic

    Design
    Bounded Context Example
    Reservations
    Event

    Management
    Badges
    Name
    Payment Details
    Adress
    Company
    Session Registrations
    Lunch Preferences
    Name
    Job Description
    Twitter Handle
    Each Bounded Context has
    its own model of a customer
    This is a major enabler for
    independent Microservices
    Take a look at the name of
    the customer? Maybe we
    want some shared data?

    View Slide

  9. Strategic

    Design
    Bounded Context Example
    Personal

    Driving
    Service

    Center
    Car
    Think about the differences in starting the car
    or simple components such as ABS, ESP, engine
    or infotainment

    View Slide

  10. Strategic

    Design
    How to identify Bounded

    ContextS?
    Factors
    One Team
    If a Bounded Context must be managed or imple-
    mented by more than one team it is probably too big
    and should be split up.
    Language
    Models act as an Ubiquitous Language, therefore it is
    necessary to draw a line between Contexts when the
    project langeuage changes.
    Cohesion
    Take a look at your (sub-) domain and think about
    which parts of that domain are strongly related or in
    other words highly cohesive.
    Meaningful
    Model
    Try to identify models that make sense and that are
    meaningful in one specific context. Also think about
    decoupling of models.

    View Slide

  11. Strategic Design
    Strategic Design
    consists of
    Bounded Context
    Context Map
    Shared
    Kernel
    Customer
    / 

    Supplier
    Conformist
    Anticorruption

    Layer
    Separate
    Ways
    Open
    /
    Host 

    Service
    Published 

    Language

    View Slide

  12. Context Map
    Strategic

    Design
    The Bounded Context by
    itself does not deliver an
    overview of the system
    By introducing a Context
    Map we describe the contact
    between models / contexts
    The Context Map is also a
    great starting point for
    future transformations

    View Slide

  13. Strategic

    Design
    Context Map - Patterns
    Shared
    Kernel
    Customer
    / 

    Supplier
    Conformist
    Anticorruption

    Layer
    Separate
    Ways
    Open
    /
    Host 

    Service
    Published 

    Language

    View Slide

  14. Strategic

    Design
    Context Map - Patterns
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    Two teams share a subset of the domain
    model including code and maybe the
    database. The shared kernel is often
    refered to as the core domain.

    View Slide

  15. Strategic

    Design
    Context Map - Patterns
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    There is a customer / supplier
    relation ship between two teams. The
    downstream team is considered to be
    the customer, sometimes with veto
    rights.

    View Slide

  16. Strategic

    Design
    Context Map - Patterns
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    The downstream team conforms to the
    model of the upstream team. There is
    no translation of models and no
    vetoing. If the upstream model is a
    mess, it propagates to the downstream
    model.

    View Slide

  17. Strategic

    Design
    Context Map - Patterns
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    The anticorruption layer is a layer
    that isolates a client’s model from
    another system’s model by translation.

    View Slide

  18. Strategic

    Design
    Context Map - Patterns
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    There is no connection between the
    bounded contexts of a system. This
    allows teams to find their own
    solutions in their domain.

    View Slide

  19. Strategic

    Design
    Context Map - Patterns
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    Each Bounded Context offers a defined
    set of services that expose
    functionality for other systems. Any
    downstream system can then implement
    their own integration. This is
    especially useful for integration
    requirements with many other systems.

    View Slide

  20. Strategic

    Design
    Context Map - Patterns
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    Published Language is quite similar to
    Open / Host Service. However it goes
    as far as to model a Domain as a
    common language between bounded
    contexts.

    View Slide

  21. Strategic

    Design
    Context Map - Why?
    Credit

    Application
    Credit

    Decision
    Scoring
    Credit

    Agency
    CRM

    View Slide

  22. Strategic

    Design
    Context Map - Why?
    Credit

    Application
    Credit

    Decision
    Scoring
    Credit

    Agency
    CRM
    Currently we only see call
    stacks

    View Slide

  23. Strategic

    Design
    Context Map
    Credit

    Application
    Credit

    Decision
    Scoring
    Credit

    Agency
    CRM
    U
    D
    D
    D
    D
    U
    U
    U
    C

    F
    O

    H

    S
    C

    U

    S
    O

    H

    S
    O
    H
    S
    A C
    L
    S
    K
    S
    K

    View Slide

  24. Strategic

    Design
    and Conway’s Law
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language

    View Slide

  25. Strategic

    Design
    and Conway’s Law
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    Team
    Communication

    View Slide

  26. Strategic

    Design
    and Conway’s Law
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    Team
    Communication

    View Slide

  27. Tight Coupling /
    Integration
    Strategic

    Design
    and Conway’s Law
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    Team
    Communication

    View Slide

  28. Tight Coupling /
    Integration
    Strategic

    Design
    and Conway’s Law
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    Team
    Communication

    View Slide

  29. Team
    independence
    Tight Coupling /
    Integration
    Strategic

    Design
    and Conway’s Law
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    Team
    Communication

    View Slide

  30. Strategic

    Design
    Where do Context Maps help?

    View Slide

  31. Strategic

    Design
    Where do Context Maps help?
    Governance
    A Context Map helps to identify governance issues
    between applications and teams.
    Transformation
    A Context Map is an excellent starting point for future
    transformations: it gives an in-depth insight into
    integration aspects and subdomain / context mathesxw
    Bad Models
    By introducing a Context Map we get a clear view on
    where and how bad models propagate through
    application landscapes
    Politics
    By not just looking at technical integration aspects the
    Context Map also helps us in seeing how teams
    communicate and „play politics“.

    View Slide

  32. Domain Driven Design
    helps us with

    Microservices in four
    areas
    Strategic Design
    (Internal) 

    Building Blocks
    Large Scale

    Structure
    Destillation

    View Slide

  33. Building Blocks
    help designing 

    the internals of

    Bounded Contexts
    Aggregates
    (Internal) 

    Building Blocks
    Entities
    Value Objects
    Factories
    Services
    Repositories

    View Slide

  34. 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

  35. 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

  36. 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

  37. Building

    Blocks
    Aggregates
    Do not
    underestimate
    the power of
    the Aggregate

    View Slide

  38. 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

  39. Building

    Blocks
    Factories, Services, 

    Repositories
    Aggregates
    Entities
    Value Objects
    Factories
    Services
    Repositories
    Factories take care of Entity- /
    Aggregate-Instantiations
    Repositories encapsulate and
    represent data access
    Services implement business
    logic that relates to multiple
    Entities / Aggreates

    View Slide

  40. Building

    Blocks
    Align the internal building blocks

    along Application Services
    and the Domain Model
    Input
    Adapter
    Web
    Mobile
    Cloud
    Messaging
    Database
    Document
    GraphDB
    Messaging
    Output
    Adapter
    Application

    Service
    Domain

    Model
    Persistence
    Domain Events
    Domain Events

    View Slide

  41. Building

    Blocks
    Align the internal building blocks

    along Application Services
    and the Domain Model
    Input
    Adapter
    Web
    Mobile
    Cloud
    Messaging
    Database
    Document
    GraphDB
    Messaging
    Output
    Adapter
    Application

    Service
    Domain

    Model
    Persistence
    Domain Events
    Domain Events
    I never heard of 

    DOMAIN EVENTS
    before!

    View Slide

  42. „After inserting data into“
    „We need to check the status of“
    „When we have called System X“
    „If that happens“
    „After the customer has“
    „Notify me if“
    „When ..“

    View Slide

  43. „After inserting data into“
    „We need to check the status of“
    „When we have called System X“
    „If that happens“
    „After the customer has“
    „Notify me if“
    „When ..“
    Ubiquitous

    Language

    anyone?

    View Slide

  44. ! Domain Events are
    something that
    happened that Domain
    Experts care about

    View Slide

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

    View Slide

  46. Triggers of Events
    Documents
    Time
    Applications
    User Actions

    View Slide

  47. Loan Details
    Entered
    Financial
    Situation
    Entered
    Personal
    Infromation
    Entered
    Application
    Submitted
    Credit

    Application
    Scoring
    Credit

    Decision
    Customer

    View Slide

  48. Domain Driven Design
    helps us with

    Microservices in four
    areas
    Strategic Design
    (Internal) 

    Building Blocks
    Large Scale

    Structure
    Destillation

    View Slide

  49. Large Scale Structure
    helps evolving our
    Microservice
    landscapes
    Evolving

    Order
    Large Scale

    Structure
    System

    Metaphor
    Resposibility

    Layers

    View Slide

  50. Large

    Scale

    Structure
    Evolving Order

    View Slide

  51. Large

    Scale

    Structure
    Evolving Order
    Job Title: 

    Chief Ivory Tower Architect

    View Slide

  52. Large

    Scale

    Structure
    Evolving Order
    Job Title: 

    Chief Ivory Tower Architect
    Rigid Development Guidelines
    Inflexible Architecture


    Clear rules and conventions for
    everything
    „I don’t need expensive
    developers, I prefer cheap ones
    and I do the thinking for them“

    View Slide

  53. Large

    Scale

    Structure
    Evolving Order
    Development Team
    System is too complex
    Let’s dumb down the system to
    fit the rules


    We need a workaround to
    undermine some rules

    View Slide

  54. Sounds
    familiar in a
    microservice
    environment?
    Large

    Scale

    Structure
    Evolving Order
    Evolving

    Order
    Let large structures evolve, don’t
    overconstrain design principles
    These large structures should be
    applicable across bounded contexts
    However there should be some
    practical constraints

    View Slide

  55. Large

    Scale

    Structure
    Responsibility Layers
    Registration
    Event

    Management
    Badges
    Mailings
    Speakers

    View Slide

  56. Large

    Scale

    Structure
    Responsibility Layers
    Registration
    Event

    Management
    Badges
    Mailings
    Speakers
    Each of these Microservices
    is structures according to a
    bounded context
    Inside these context
    developers have the chance
    to use building blocks
    However we could structure
    our bounded context
    according to responsibilities

    View Slide

  57. Domain Driven Design
    helps us with

    Microservices in four
    areas
    Strategic Design
    (Internal) 

    Building Blocks
    Large Scale

    Structure
    Destillation

    View Slide

  58. Destillation
    helps extracting
    Microservices out of
    an existing
    monolithic
    application
    Destillation

    View Slide

  59. Destilla-

    tion
    Identify the core domain
    Destillation Document
    Describes all the
    details of the core
    domain
    Vision Statement
    Defines what is in the
    core domain and what
    is not in the core
    domain

    View Slide

  60. Destilla-

    tion
    Extract subdomains
    Identification of subdomain
    Extraction from core
    Clean separation
    Internal refactoring

    View Slide

  61. Microservices
    Domain Driven Design
    Strategic Design
    (Internal) 

    Building Blocks
    Large Scale

    Structure
    Destillation
    <3

    View Slide

  62. THANK YOU!
    <3
    Michael Plöd - innoQ

    @bitboss
    Shameless plug: we offer DDD trainings and consulting

    View Slide