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

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