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


 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 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.” –https://www.wildmind.org/tag/near-enemy

“MODERNISING CRIMINAL JUSTICE” Andrew Andrew Starts Finishes Gayathri Gayathri Starts Finishes

KEY CONSTRAINTS • Modernisation of the end-to-end justice lifecycle (spanning multiple organisations) • Teams already identified and code already being cut • CQRS everywhere

INCREDIBLY HIGH STAKES

PART 1: IN THE BEGINNING…

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

Design has been done, Make sure all your design but it hasn't been laid artefacts are created out in a way that makes with the audience in it consumable. mind.

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

SIMILAR (BUT NOT THE SAME) https://www.flickr.com/photos/chiropractic/6849052708

EXAMPLE: DOMAIN GENERIFICATION

Similarities have been Capture the richness of spotted, and abstractions the domain in the core made. entities. But important differences Don’t abstract too early. have been lost in the process.

EXAMPLE: DATA CENTRIC

A data-based view has Sharing models and code been achieved at the between teams is really expense of process / difficult. behaviour, Only share what you Conflicts between teams need to. have resulted.

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

PROBLEM: OWNERSHIP

Hands on modellers Everyone manipulates the aren't hands on. code. They aren't manipulating If certain team members their models and using can't, get them pairing. them to try and solve real-world problems.

WHAT ABOUT THE OTHER SIDE?

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

LEGAL SYSTEMS ARE NECESSARILY COMPLEX

LEGAL SYSTEMS ARE RIPE FOR DOMAIN DRIVEN DESIGN

PART II: DOING THE DOING

HOW DO THE KEY PIECES FIT TOGETHER?

Not having any10,000- Just because one foot view when working structural "big idea" is wrong, doesn't mean you at scale. can get away with nothing. Relationships between models are always key.

REASONS FOR A SHARED CASE MODEL? • Data consistency • Reporting • Planning • Simplified access control • But what about business-domain needs?

PROBLEM: DATA-NOT-PROCESS

Solving one problem at Don't ignore the tensions between problems. the expense of another. Use DDD tools to make them, and their solutions, explicit.

SOLUTION: AN ABSTRACT CORE?

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

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

SPLITS —> SILOS

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

PROBLEMS: ICEBERGS AND ICE CUBES

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

SOLUTION: THE END-TO-END VIEW

SEEING THIS IN ACTION

THE EMERGING IMPLEMENTATION

SHORT SIGHT SHORT SIGHT VS VS LONG SIGHT LONG SIGHT

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

AS-IS VS TO-BE VICIOUS CYCLE

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

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

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

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

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

CONCLUSIONS • Slow down and listen - • Investigate puzzles - they especially for differences have solutions hidden inside • The domain already knows • Work with the code - a how to split things up lot • Distinguish as-is from to-be • Work as a team - DDD is for everyone • Don't dilute - distill

THANK YOU (WHAT QUESTIONS CAN I ANSWER?)