DDD Workshop @ Microxchg

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