Domain Driven Design Kevin van der Vlist

Size: px

Start display at page:

Download "Domain Driven Design Kevin van der Vlist"

Beryl Morris
6 years ago
Views:

1 Domain Driven Design Kevin van der Vlist

2 Objectives 1. Show the usefullnes of DDD 2/27

3 Objectives 1. Show the usefullnes of DDD 2. Warn you about a two headed monster 2/27

4 Objectives 1. Show the usefullnes of DDD 2. Warn you about a two headed monster 3. Highlight two core concepts of DDD 2/27

5 Problems Threats for developing software systems in real life

6 Implicit knowledge Implicit (business) knowledge is, if codified at all, often added to software as an afterthought: Only shows up as defects (I expected that..., doing so should...) Arises later then needed in the development process, possibly hiding key abstractions Because they are implicit they are hard to validate: what is correct behaviour? 4/27

7 architecture- for- developers/read

9 Domain Driven Design What are the key concepts?

10 Key Concepts Domain and model 8/27

11 Key Concepts Domain and model Ubiquitous language 8/27

12 Key Concepts Domain and model Ubiquitous language Bounded context 8/27

14 Two-headed monster? Part II The building blocks of a Model-Driven Design Ubiquitous Language Part IV Strategic Design Figure: 10/27

15 Ubiquitous language

16 Ubiquitous language A language structured around the domain model that is used by all stakeholders to connect all the activities directly with software. Grasping customer concepts and detecting inconsistencies Shared language with domain expert Business concepts become first class citizens of the code. Multiple domains get their own language Bridges gap between business, technology and other domains 12/27

17 Ubiquitous language In short: Unambigous Embedded in code and daily vocabulary Used by every single stakeholder 13/27

18 DDD Primitives The building blocks of a Model-Driven Design

19 Primitives Building blocks for DDD Received most attention because they are in the first part of the book Actually just implementation details 15/27

21 Primitives Building blocks for DDD Received most attention because they are in the books first part Actually just implementation details Not the essence of DDD 17/27

22 Most important primitive Aggregate Cluster of domain objects Accessible via the root object Provides a transactional boundary 18/27

23 Most important primitive Aggregate Cluster of domain objects Accessible via the root object Provides a transactional boundary Example: Car Window... Engine... Wheel Tire Axel Hubcap 18/27

24 Strategic design Bounded Context

25 Bounded Context To deal with large models, DDD divides them in different, separated Bounded Contexts Their relations are explicit since they can only occur at domain boundaries Integrate bounded context at the borders (using events) In each individual bounded context, focus on that specific domain and use an explicitly separated ubiquitous language. 20/27

27 Prevent monopolization! Make sure that each domain gets their own context 22/27

29 Bounded Context Localise the effects of various contexts within your domain 24/27

30 Wrapping up

31 Wrapping up 1 Show the usefullnes of DDD Make the domain as explicit as you can 26/27

32 Wrapping up 1 Show the usefullnes of DDD Make the domain as explicit as you can 2 Warn you about a two headed monster Strategic design: the actual essence of DDD 26/27

33 Wrapping up 1 Show the usefullnes of DDD Make the domain as explicit as you can 2 Warn you about a two headed monster Strategic design: the actual essence of DDD 3 Highlight two core concepts of DDD Bounded context and aggregate root: a killer combo 26/27

34 Questions? 27/27

35 Architectural patterns with Domain Driven Design

36 Architectural patterns: Microservices Microservices 29/27

37 Architectural patterns: Microservices Highly visible right now. Accelerated by culture and tooling around DevOps, Agile, Continuous Integration, Continuous Delivery etc. 30/27

39 Architectural patterns: Microservices Physically splitting up monoliths Organized around business capabilities (which are bounded contexts) If certain rules are followed this pattern can be highly scalable and available. Development of individual contexts is as loosely coupled as it can be (separate languages, systems,...) 32/27

40 Architectural patterns: Microservices CQRS 33/27

41 Architectural patterns: CQRS Based on Bertrand Meyer s Command and Query Separation (CQS) Methods either retrieve data (side effect free): Person.Move(newAddress) Or change state (obviously has a side effect): Address address = Person.GetAddress() 34/27

42 Architectural patterns: CQRS Command Query Separation (CQS): separate reads and writes in their own actions Command Query Responsibility Segregation (CQRS):... and in their own classes... and in their own modules... and in their own deployables... and in their own runtime process... and in their own servers... and in their own databases 35/27

44 Architectural patterns: CQRS What happens? Scaling of reads and writes Different, physically separated representations of the same data Application level sharding (for example: geographic regions of the same applications) 37/27

45 Architectural patterns: CQRS What happens? Scaling of reads and writes Different, physically separated representations of the same data Application level sharding (for example: geographic regions of the same applications) Eventual Consistency 37/27

46 Architectural patterns: Event Sourcing Event Sourcing 38/27

47 Architectural patterns: Event Sourcing What is an event? A description of something that happened at a specific moment in time. Past tense Contains all relevant information about the something It already happened, it cannot be ignored, deleted or mutated. 39/27

48 Architectural patterns: Event Sourcing The trick is: expose the domain as an observable sequence of events and do this in pure business terms MortgageRequestReceived MortgageRequestApproved MortgageClosed MonthlyRepaymentReceived ExtraRepaymentReceived 40/27

49 Architectural patterns: Event Sourcing What is the current due ammount of a loan? Most systems define state as leading: they store a value to represent the answer. Event sourcing makes it a derivative: it is calculated by applying events over time to a shared state. To put it differently: it basically is a foldl of facts: state = ((((a + b) + c) + d) +...) 41/27

50 Architectural patterns: Event Sourcing By deriving state from events you get a few things for free: Following state through time Changing the way you represent data but without losing any Applying temporal queries on your data. 42/27

51 Architectural patterns: Event Sourcing By deriving state from events you get a few things for free: Following state through time Changing the way you represent data but without losing any Applying temporal queries on your data. Canonical example of Greg Young: I as a Doctor want to find patients for a clinical trial. I am looking for patients that were diagnosed with pancreatic cancer within the last 6 months. Within 1 week of diagnosis they were placed on treatment T1 and were given the treatment more than 3 times but less than 7 within a 3 week period. They then failed the treatment with a lab result that looks like R1. They were then placed on a treatment T2 within two weeks and failed with a lab result that looked like R2. 42/27

52 Architectural patterns: Actor model Actor model 43/27

53 Architectural patterns: Actor model See Reactive-Messaging-Patterns-Actor-Model/ dp/ /27

Domain Driven Design IS. An architectural methodology for evolving a software system that closely aligns to business requirements

Domain Driven Design IS. An architectural methodology for evolving a software system that closely aligns to business requirements Domain Driven Design IS An architectural methodology for evolving a software system that closely aligns to business requirements Domain Driven Design IS Domain First Focus on the Object Model Focus on