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

Microservices love Domain-driven Design - Version 2

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.

Michael Plöd

May 14, 2018
Tweet

More Decks by Michael Plöd

Other Decks in Programming

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