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?)
Recommend
More recommend
