Microservices love Domain-driven Design - Version 2

This is a new version of my talk about Microservices and DDD. It was first presented at the MicroCPH conference in Copenhagen, Denmark.

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 than ever.

This talk explains how the patterns and concepts of Domain Driven Design relate to Microservice architectures. We will see that Microservices are not only about Bounded Contexts and that there is much more to Domain Driven Design than Entities and Aggregates. In addition to that I will show 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). Finally, we will look into migrating existing monolithic applications with the help of patterns laid out in DDD.

Transcript

1. Microservices
   Domain-driven Design
   Michael Plöd, @bitboss
   <3
   

   View Slide

2. Check out my book
   https://leanpub.com/ddd-by-example
   This book aims to explain the concepts of Domain-
   driven Design in a way that it is easily applicable in
   practice. Each chapter contains a theoretical part
   which is explained from the point of view of
   practical applicability and then exercises with
   solutions based on a comprehensive, complex case
   study (real estate loans).
   

   View Slide

3. https://leanpub.com/ddd-by-example
   https://leanpub.com/ddd-referenz/
   

   View Slide

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

5. Feel free to replace developer by architect, team lead, team
   member or domain expert.
   Neither Domain-driven Design nor Microservices are silver
   bullets that solve all your problems just by applying them.
   

   View Slide

6. Domain-driven Design

   and

   Microservices
   a few disclaimers
   DDD and Microservices
   are not just about
   Bounded Contexts
   DDD itself is not just
   about Aggregates,
   Entities and Services
   

   View Slide

7. Domain-driven Design
   is not

   about technologies
   

   View Slide

8. Business

   Domain

   Experts
   Developers

   Architects
   D

   D
   D
   

   View Slide

9. Technical Language Business Language
   Business Folks
   Developers Domain Experts
   IT Folks
   Tracking 

   Postgres
   AI

   Engine
   Rabbit

   Messaging
   Results

   MySQL
   Parcel
   Sent
   Predict

   Delivery
   Recipient

   Notified
   

   View Slide

10. Technical Language Business Language
    Business Folks
    IT Folks
    Ubiquitous Language
    Domain Experts
    Developers
    

    View Slide

11. DOMAIN MODEL
    Domain Experts
    Developers
    Ubiquitous Language
    Conversations
    Code
    Drawings Documentation
    

    View Slide

12. Model your
    Microservices along
    business capabilities
    

    View Slide

13. Subdomains and Domain Models
    

    View Slide

14. Goal: independence of systems
    Not with a central
    domain model
    

    View Slide

15. Goal: independence of systems
    Design &
    Implementation
    Releasing &
    Deployment
    Runtime & Operations
    

    View Slide

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

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

18. Example - You at Java Forum
    Stuttgart
    Reservations
    Event

    Management
    Badges
    Java Forum 

    Stuttgart

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

    View Slide

19. A Bounded Context is the 

    BOUNDARY

    for the meaning of a model
    

    View Slide

20. Don’t
    Repeat
    Yourself
    

    View Slide

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

    View Slide

22. Repeat
    Yourself
    BETWEEN
    several
    Bounded
    Contexts
    

    View Slide

23. Cut your

    Microservices
    

    along
    Bounded
    Contexts
    

    View Slide

24. Don’t
    Repeat
    Yourself
    INSIDE
    of a
    Bounded
    Context
    Mic rose rvice
    

    View Slide

25. Repeat
    Yourself
    BETWEEN
    several
    Bounded
    Contexts
    Mic rose rvices
    You may want to
    

    View Slide

26. Mind Conway’s Law when
    dealing with communication
    between Microservices
    

    View Slide

27. Continuous Delivery is an important enabler
    for the agile, cultural part of DDD
    Business

    Domain

    Experts
    Developers

    Architects
    Operations

    DDD
    Dev

    Ops
    

    View Slide

28. DDD
    Software

    Engineering
    Domain

    Knowledge
    Agile
    

    View Slide

29. Communication between Contexts
    Call Flow
    How are calls and events
    flowing within a
    system / context
    landscape?
    Model Flow
    How do models
    propagate between
    systems? Where are
    boundaries?
    Influence Flow
    How do the actions of
    one team affect other
    teams? Who influences
    whom?
    or or
    Team
    Communication /
    Politics
    How do teams
    communicate with each
    other? Where are
    politics being played?
    or or
    

    View Slide

30. Eric Evans defined those seven 

    context mapping patterns
    Context Map Patterns by the books
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    

    View Slide

31. Vaughn Vernon added two more
    patterns to the list
    Context Map Patterns by the books
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    Partnership
    Big Ball Of Mud
    

    View Slide

32. Where should 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 relations
    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

33. Upstream / Downstream
    Credit Agency
    Scoring
    Influence

    Flow
    Upstream System
    Downstream System
    Actions of the upstream team, have a

    direct impact on the downstream team.
    

    View Slide

34. Categories for 

    Context Mapping Patterns
    

    View Slide

35. Context Map Patterns Categorized
    Credit Agency
    Scoring
    Upstream-centric Patterns:
    • Open Host Service
    Downstream-centric Patterns:
    • Customer / Supplier
    • Conformist
    • Anticorruption Layer
    Bilateral Patterns:
    • Shared Kernel
    • Separate Ways
    • Published Language
    

    View Slide

36. Context Map Patterns Categorized
    Credit Agency
    Scoring
    Upstream-centric Patterns:
    • Open Host Service
    Downstream-centric Patterns:
    • Customer / Supplier
    • Conformist
    • Anticorruption Layer
    Bilateral Patterns:
    • Shared Kernel
    • Separate Ways
    • Published Language
    

    View Slide

37. Open Host Service
    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.
    SOAP / REST for
    example
    

    View Slide

38. Context Map Patterns Categorized
    Credit Agency
    Scoring
    Upstream-centric Patterns:
    • Open Host Service
    Downstream-centric Patterns:
    • Customer / Supplier
    • Conformist
    • Anticorruption Layer
    Bilateral Patterns:
    • Shared Kernel
    • Separate Ways
    • Published Language
    

    View Slide

39. Customer / Supplier
    Upstream System
    Downstream System
    There is a customer / supplier relation
    ship between two teams. The down-
    stream team is considered to be the
    customer not having a full influence but
    has some influence.
    Downstream Team
    discusses model with
    Upstream Team
    

    View Slide

40. Conformist
    Upstream System
    Downstream System
    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.
    The Downstream
    Team adapts to the
    model of the
    Upstream Team
    

    View Slide

41. Anticorruption Layer
    The anticorruption layer is a layer that
    isolates a client’s model from another
    system’s model by translation.
    External model to
    internal model
    transformation
    

    View Slide

42. Context Map Patterns Categorized
    Credit Agency
    Scoring
    Upstream-centric Patterns:
    • Open Host Service
    Downstream-centric Patterns:
    • Customer / Supplier
    • Conformist
    • Anticorruption Layer
    Bilateral Patterns:
    • Shared Kernel
    • Separate Ways
    • Published Language
    

    View Slide

43. Shared Kernel
    Two teams share a subset of the domain
    model including code and maybe the
    database.
    Shared
    Kernel
    

    View Slide

44. Separate Ways
    There is no connection between the
    bounded contexts of a system. This
    allows teams to find their own solutions
    in their domain.
    However there may be a „hidden“
    connection between the teams. Look out
    of for „organizational“ Solutions (Excel,
    Access, ..)
    

    View Slide

45. 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.
    Typical examples are iCal or vCard.
    Implements according
    to Published Language
    Implements according
    to Published Language
    

    View Slide

46. Example: iCal
    The top-level element in iCalendar is the Calendaring and Scheduling Core
    Object, a collection of calendar and scheduling information. Typically, this
    information will consist of a single iCalendar object. However, multiple
    iCalendar objects can be grouped together.
    The first line must be BEGIN:VCALENDAR, and the last line must
    be END:VCALENDAR; the contents between these lines is called the
    "icalbody".

    The second line VERSION:2.0 indicates that the data is in iCalendar
    format. VERSION:1.0 was used to specify that data is in the old vCalendar
    format.
    The body of the iCalendar object (the icalbody) is made up of a list of
    calendar properties and one or more calendar components. The calendar
    properties apply to the entire calendar. The calendar components are
    several calendar properties which create a calendar schematic (design).
    For example, the calendar component can specify an event, a to-do list, a
    journal entry, time zone information, or free/busy time information, or an
    alarm. Empty lines are not allowed in some versions of usage (Google
    calendar).
    Source: https://en.wikipedia.org/wiki/ICalendar
    

    View Slide

47. Example: vCard
    vCard, also known as VCF (Virtual Contact File), is a file format standard for electronic business cards. vCards are often
    attached to e-mail messages, but can be exchanged in other ways, such as Multimedia Messaging Service(MMS), on
    the World Wide Web, instant messaging or through QR code. They can contain name and address information, telephone
    numbers, e-mail addresses, URLs, logos, photographs, and audio clips.
    vCard is used as data interchange format in personal digital assistants (PDAs), personal information managers (PIMs)
    and customer relationship management (CRMs). To accomplish these data interchange applications, other "vCard
    variants" have been used and proposed as "variant standards", each for its specific niche: XML representation, JSON
    representation, or web pages.
    Source: https://en.wikipedia.org/wiki/VCard
    

    View Slide

48. Context Maps and Conway’s Law
    Team
    independence
    Tight Coupling /
    Integration
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    Team
    Communication
    

    View Slide

49. U
    D
    D U
    U
    D
    Example: Context Maps
    Credit

    Application
    Scoring
    Credit

    Agency
    Customer
    Customer

    Contact
    O

    H

    S
    C

    F
    S
    K
    SUP
    ACL
    OHS
    C
    U

    S
    

    View Slide

50. Microservice architectures
    should be evolvable
    

    View Slide

51. Aggregates
    (Internal) 

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

    View Slide

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

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

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

55. Value
    Objects
    Expressiveness
    Value Objects add expressive names to key concepts in
    a model and increase the conceptual cohesiveness of
    objects.
    Focus for
    Entities
    Value Objects allow entities to focus on identity by
    delegating behavioral logic to them.
    Domain
    Concepts
    Value Objects enable moving from using primitives for
    simple domain concepts like postcode of an address.
    

    View Slide

56. Entity
    Value Value
    Using only Entities and Value
    Objects you will end up with
    big object graphs
    

    View Slide

57. Issues related to big object graphs
    Issues
    Navigation
    Endless navigation possibilities lead to less
    understandable code and is harder to maintain.
    Mind the „Law Of Demeter“.
    Consistency
    Big object graphs usually lead to large
    transactional boundaries and to a „everything
    must be consistent right now“ attitude.
    Cascading of
    errors
    The bigger the object graph, the easier it is for
    bugs to propagate or to pop up at places no one
    would expect.
    Testing
    Big and growing object graphs are hard to test.
    Sooner or later you end up with a ton of mocks.
    

    View Slide

58. Loose
    Coupling
    +
    Information
    Hiding
    +
    Cohesion
    Lets talk about
    

    View Slide

59. Entity
    Value Value
    Neither loose coupling, nor
    information hiding or cohesion
    are achieved with large object
    graphs
    

    View Slide

60. Building

    Blocks
    Aggregates
    Do not
    underestimate
    the power of
    the Aggregate
    

    View Slide

61. Aggregates group Entities and Value Objects
    

    View Slide

62. ROOT ROOT
    ROOT ROOT
    Each Aggregate has a Root Entity, aka
    Aggregate Root
    

    View Slide

63. Aggregates
    Domain
    Concepts
    Aggregates represent higher level business
    concepts.
    Behavior
    Try moving behavior to Value Objects in the
    Aggregates. The Entities should deal with lifecycle
    and identitiy.
    Invariants
    Aggregates allow us to implement and enforce
    rules and invariants (a fincancial situation must
    have in- and outgoings)
    

    View Slide

64. Connascence
    „In software engineering, two components are connascent if a
    change in one would require the other to be modified in order to
    maintain the overall correctness of the system.“
    https://en.wikipedia.org/wiki/Connascence
    

    View Slide

65. Mind Microservice
    integration styles
    

    View Slide

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

    View Slide

67. Choreography
    Credit

    Application
    Scoring
    Credit
    Decision
    Customer
    Credit

    Application

    Submitted
    Event
    

    View Slide

68. Credit

    Application

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

    View Slide

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

    View Slide

70. An event is something 

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

    View Slide

71. How do I identify events?
    

    View Slide

72. Event
    Storming
    !
    

    View Slide

73. Invite the right people
    Provide unlimited 

    modelling space
    Explore the domain starting 

    from Domain Events
    Explore the the origins of
    Domain Events
    Look for Aggregates
    Source: http://ziobrando.blogspot.de/2013/11/introducing-event-storming.html
    Avoid tables / chairs

    in the room
    

    View Slide

74. Command
    Aggregate
    Domain

    Event
    External 

    System
    Read

    Model
    Policy
    Command
    on
    on
    returns
    returns
    updates
    triggers
    invokes
    invokes
    

    View Slide

75. REST + Events

    =

    Feeds
    

    View Slide

76. Application
    Approved
    Event
    Credit
    Decision
    The Credit Decision
    Microservice publishes the
    Application Approved Events
    as an Atom Feed via HTTP
    Contract Offers
    The Contract Offers
    Microservice polls the HTTP
    based Atom Feed at a
    predefined rate
    

    View Slide

77. In order to offer
    Feeds we must?
    Persist our
    Domain Events!
    

    View Slide

78. Event Sourcing is an
    architectural pattern
    in which the state of
    the application is
    being determined by a
    sequence of events
    

    View Slide

79. Using the ideas
    behind CQRS
    we can derive
    views that are
    optimized for
    queries from
    the event store
    

    View Slide

80. Migrating from monoliths
    to Microservices
    

    View Slide

81. Starting point:
    The monolith
    from the gates of hell
    

    View Slide

82. Bounded Contexts
    Top
    Down
    Context Maps
    Bottom
    Up
    Aggregates
    Microservice
    Candidates
    

    View Slide

83. !Never perform a big bang
    migration. Work in small
    steps and each step should
    deliver an improvement.
    

    View Slide

84. Microservices
    Domain-driven Design
    Michael Plöd, @bitboss
    <3
    

    View Slide

85. Check out my book
    https://leanpub.com/ddd-by-example
    This book aims to explain the concepts of Domain-
    driven Design in a way that it is easily applicable in
    practice. Each chapter contains a theoretical part
    which is explained from the point of view of
    practical applicability and then exercises with
    solutions based on a comprehensive, complex case
    study (real estate loans).
    

    View Slide