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

DDD Workshop @ Microxchg

DDD Workshop @ Microxchg

21a532a137b506128914478ac521fc8b?s=128

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

  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
  3. Motivation > Strict separation between IT and business > Waterfall

    model did not deliver desired results > Strong divergences in > Architecture > Business Rules > Organisation
  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
  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
  6. Parts of DDD Strategic Design (Internal) 
 Building Blocks Large

    Scale
 Structure Destillation
  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
  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
  9. Example Reservations Event
 Management Badges Customer Name Payment Details Adress

    Company Session Registrations Lunch Preferences Name Job Description Twitter Handle
  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
  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
  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
  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.
  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.
  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.
  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.
  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.
  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.
  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.
  20. Draw a Context Map https://github.com/mploed/ddd-strategic-design-spring-boot

  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
  22. Usual Architecture Patterns > Event-Driven Architecture > REST > SOA

    > Microservices / Self-Contained Systems > CQRS > Reactive / Actor Model
  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
  24. Domain Events Customer
 Notification
 Bounded Context Shipping
 Bounded
 Context Shipment


    Delivered
 Event Messaging
 System Shipment
 Delivered
 Event
  25. An event is something 
 that happened in the past

    t now Event Event Event Event Event
  26. The names of the events are part of the
 Ubiquitous

    Language D D D
  27. ShipmentDeliveredEvent
 CustomerVerifiedEvent CartCheckedOutEvent CreateCustomerEvent
 WillSaveItemEvent
 DoStuffEvent

  28. Scope your events based on
 Aggregates D D D

  29. An Event is always immutable !