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

DDD Workshop @ Microxchg

DDD Workshop @ Microxchg

Michael Plöd

March 01, 2017
Tweet

More Decks by Michael Plöd

Other Decks in Programming

Transcript

  1. Domain Driven Design
    Microxchg
    Michael Plöd

    View Slide

  2. Origins
    > Books by Eric Evans and Vaughn Vernon
    > More relevant than ever in the advent of microservices
    > Implicit dependencies are getting explicit
    > Various advancements:
    > Domain Events
    > Event Sourcing / CQRS
    > Event Storming

    View Slide

  3. Motivation
    > Strict separation between IT and business
    > Waterfall model did not deliver desired results
    > Strong divergences in
    > Architecture
    > Business Rules
    > Organisation

    View Slide

  4. Key aspects
    > Don’t mistake DDD as a plain collection of (design) patterns
    > DDD is rather a collection of attitudes, organizational aspects and
    some patterns
    > DDD focusses on a very agile approach
    > DDD has impact on development, software-architecture, enterprise-
    architecture, team organization and project management

    View Slide

  5. Core-learnings
    > The Domain is the heart of the system
    > Concepts of the domain will be reflected in the (software) design
    > Engineering over technology
    > Attitude over strict plans
    > Culture over a fixed collection of principles
    > Continuous learning
    > Ubiquitous language

    View Slide

  6. Parts of DDD
    Strategic Design
    (Internal) 

    Building Blocks
    Large Scale

    Structure
    Destillation

    View Slide

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

    Supplier
    Conformist
    Anticorruption

    Layer
    Separate
    Ways
    Open
    /
    Host

    Service
    Published

    Language
    Strategic Design

    View Slide

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

  9. Example
    Reservations
    Event

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

    View Slide

  10. Example
    > Each Bounded Context has its own model of
    a customer
    > This is a major enabler for independent
    microservices
    > Name might be a use case for shared data
    but does not have to be

    View Slide

  11. Context Map - 1
    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

  12. Context Map - 2
    The Context Mapping
    Patterns are no Best
    Practices, they describe a
    current state
    Context Mapping usually
    adresses existing landscapes
    You can identify interesting
    hotspots in existing
    landscapes

    View Slide

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

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

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

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

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

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

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

  20. Draw a Context Map
    https://github.com/mploed/ddd-strategic-design-spring-boot

    View Slide

  21. Context Map Example
    Shop
    Online

    Ads
    Warehouse Logistics
    Payment
    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

  22. Usual Architecture Patterns
    > Event-Driven Architecture
    > REST
    > SOA
    > Microservices / Self-Contained Systems
    > CQRS
    > Reactive / Actor Model

    View Slide

  23. Domain Events
    > Bounded Contexts can issue Domain Events
    > Domain Events are important occurrences in an Domain
    > UserVerified
    > ShoppingCartCheckedOut
    > ShipmentDelivered
    > Domain Events are usually based on eventual consistency
    > Major driver for high degree of decoupling between
    Bounded Contexts

    View Slide

  24. Domain Events
    Customer

    Notification

    Bounded
    Context
    Shipping

    Bounded

    Context
    Shipment

    Delivered

    Event
    Messaging

    System
    Shipment

    Delivered

    Event

    View Slide

  25. An event is something 

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

    View Slide

  26. The names of the events are part
    of the

    Ubiquitous Language
    D D D

    View Slide

  27. ShipmentDeliveredEvent

    CustomerVerifiedEvent
    CartCheckedOutEvent
    CreateCustomerEvent

    WillSaveItemEvent

    DoStuffEvent

    View Slide

  28. Scope your events based on

    Aggregates
    D D D

    View Slide

  29. An Event is always immutable
    !

    View Slide