DDD Workshop @ Microxchg

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 !