ADOPTING DOMAIN DRIVEN DESIGN AT SCALE Combating Near Enemies - - PowerPoint PPT Presentation

▶
adopting
SMART_READER_LITE
LIVE PREVIEW

ADOPTING DOMAIN DRIVEN DESIGN AT SCALE Combating Near Enemies - - PowerPoint PPT Presentation

Jul 01, 2023 589 likes •1.28k views

ADOPTING DOMAIN DRIVEN DESIGN AT SCALE Combating Near Enemies Andrew Harmel-Law Gayathri Thiyagarajan ANDREW HARMEL-LAW Tech Principal at ThoughtWorks GAYATHRI THIYAGARAJAN Engineering Lead at Expedia Group Near

slide-1
SLIDE 1

ADOPTING DOMAIN DRIVEN DESIGN AT SCALE

Combating Near Enemies


 Andrew Harmel-Law Gayathri Thiyagarajan

slide-2
SLIDE 2
slide-3
SLIDE 3

ANDREW HARMEL-LAW

Tech Principal 
 at
 ThoughtWorks

slide-4
SLIDE 4

GAYATHRI
 THIYAGARAJAN

Engineering Lead 
 at 
 Expedia Group

slide-5
SLIDE 5

–https://www.wildmind.org/tag/near-enemy

“Near enemies are counterfeits of what we’re actually aiming for, 
 and they're unhelpful because while the genuine article helps free us, the counterfeit doesn’t.”

slide-6
SLIDE 6

Andrew Starts Andrew Finishes Gayathri Starts Gayathri Finishes

“MODERNISING CRIMINAL JUSTICE”

slide-7
SLIDE 7

KEY CONSTRAINTS

  • Modernisation of the end-to-end justice lifecycle

(spanning multiple organisations)

  • Teams already identified and code already being

cut

  • CQRS everywhere
slide-8
SLIDE 8

INCREDIBLY HIGH STAKES

slide-9
SLIDE 9

PART 1: IN THE BEGINNING…

slide-10
SLIDE 10

KEY FINDINGS

No single domain expert had a detailed, end-to-end view No obvious "Big Picture" The cognitive load was much too high

slide-11
SLIDE 11

Design has been done, but it hasn't been laid

  • ut in a way that makes

it consumable. Make sure all your design artefacts are created with the audience in mind.

slide-12
SLIDE 12

PROBLEM: “A CASE IS A CASE IS A CASE”

slide-13
SLIDE 13
slide-14
SLIDE 14

SIMILAR (BUT NOT THE SAME)

https://www.flickr.com/photos/chiropractic/6849052708

slide-15
SLIDE 15

EXAMPLE: DOMAIN GENERIFICATION

slide-16
SLIDE 16
slide-17
SLIDE 17
slide-18
SLIDE 18
slide-19
SLIDE 19
slide-20
SLIDE 20

Similarities have been spotted, and abstractions made. But important differences have been lost in the process.

Capture the richness of the domain in the core entities. Don’t abstract too early.

slide-21
SLIDE 21

EXAMPLE: DATA CENTRIC

slide-22
SLIDE 22
slide-23
SLIDE 23

A data-based view has been achieved at the expense of process / behaviour, Conflicts between teams have resulted.

Sharing models and code between teams is really difficult. Only share what you need to.

slide-24
SLIDE 24

CORE MODEL PROBLEM SUMMARY

  • "One Model to Rule them All”
  • Design-decisions made only part of the domain

information

  • Similarities identified based solely on names
  • Models were about data. Behaviour was left out
slide-25
SLIDE 25

PROBLEM: OWNERSHIP

slide-26
SLIDE 26
slide-27
SLIDE 27

Hands on modellers aren't hands on. They aren't manipulating their models and using them to try and solve real-world problems.

Everyone manipulates the code. If certain team members can't, get them pairing.

slide-28
SLIDE 28

WHAT ABOUT THE OTHER SIDE?

slide-29
SLIDE 29

Domain Driven Design is being done "to" - rather than "by" - teams. Modelling is done by the team who own their models. Grow DDD practices

  • rganically.
slide-30
SLIDE 30

LEGAL SYSTEMS ARE NECESSARILY COMPLEX

slide-31
SLIDE 31

LEGAL SYSTEMS ARE RIPE FOR DOMAIN DRIVEN DESIGN

slide-32
SLIDE 32

PART II: DOING THE DOING

slide-33
SLIDE 33

HOW DO THE KEY PIECES FIT TOGETHER?

slide-34
SLIDE 34

Not having any10,000- foot view when working at scale.

Just because one structural "big idea" is wrong, doesn't mean you can get away with nothing. Relationships between models are always key.

slide-35
SLIDE 35

REASONS FOR A SHARED CASE MODEL?

  • Data consistency
  • Reporting
  • Planning
  • Simplified access control
  • But what about business-domain needs?
slide-36
SLIDE 36

PROBLEM: DATA-NOT-PROCESS

slide-37
SLIDE 37
slide-38
SLIDE 38

Solving one problem at the expense of another.

Don't ignore the tensions between problems. Use DDD tools to make them, and their solutions, explicit.

slide-39
SLIDE 39

SOLUTION: AN ABSTRACT CORE?

slide-40
SLIDE 40
slide-41
SLIDE 41
slide-42
SLIDE 42

Anaemic (rather than focused) abstraction. Don't jump to abstraction. Distill it from the detail

  • f specific contexts.
slide-43
SLIDE 43
slide-44
SLIDE 44
slide-45
SLIDE 45
slide-46
SLIDE 46

Abstract concepts mean little if they are not understood and implemented in code by the teams. Incrementally step towards the final model. And while incrementing, constantly validate and challenge your model.

slide-47
SLIDE 47

SPLITS —> SILOS

slide-48
SLIDE 48
slide-49
SLIDE 49

Splitting into Bounded Contexts is good. But premature splits can lead to silos which are harder to recover from. Think team relationships when splitting up bounded contexts 
 so that things don't get lost between the cracks.

slide-50
SLIDE 50

PROBLEMS: ICEBERGS AND ICE CUBES

slide-51
SLIDE 51
slide-52
SLIDE 52
slide-53
SLIDE 53

Pseudo domain complexity. Anything that is not inherently complex in the domain 
 should not be complex in the code.

slide-54
SLIDE 54

SOLUTION: THE END-TO-END VIEW

slide-55
SLIDE 55
slide-56
SLIDE 56

SEEING THIS IN ACTION

slide-57
SLIDE 57
slide-58
SLIDE 58

THE EMERGING IMPLEMENTATION

slide-59
SLIDE 59

SHORT SIGHT VS LONG SIGHT SHORT SIGHT VS LONG SIGHT

slide-60
SLIDE 60

Minimum Viable Product.

Don't constrain yourself by requirements and scope (MVP) when learning about the domain. Once learnt, implement MVP .

slide-61
SLIDE 61

AS-IS VS TO-BE VICIOUS CYCLE

slide-62
SLIDE 62

Legacy (ways of thinking). Obtain knowledge from the current state of the domain. Model the To-Be state.

slide-63
SLIDE 63

PART III: THE 
 COMPLICATED BITS PART III: THE 
 COMPLICATED BITS

slide-64
SLIDE 64

CQRS - WHAT SUITED US:

  • Human-centric way to view the Law
  • Time and eventual consistency as first-class citizens
  • Event-based thinking at its core
  • Time + Events = History
slide-65
SLIDE 65

CQRS - WHERE THERE WAS FRICTION:

  • Aggregates - Similar but not the same
  • Lack of explicit model in code
  • Read vs Write models
  • Synchronous way of thinking
  • Visualisation
slide-66
SLIDE 66

CQRS (everywhere). CQRS is powerful when used in the right place. Use it only if suggested by your domain, and even then only sparingly.

slide-67
SLIDE 67

CONCLUSIONS

  • Slow down and listen -

especially for differences

  • Work with the code - a

lot

  • Work as a team - DDD is

for everyone

  • Don't dilute - distill
  • Investigate puzzles - they

have solutions hidden inside

  • The domain already knows

how to split things up

  • Distinguish as-is from to-be
slide-68
SLIDE 68

THANK YOU

(WHAT QUESTIONS CAN I ANSWER?)