Domain driven design in the real world

We dreamed about using Domain driven design, but were stuck in the complex legacy monolith of a case management system.

While all examples and tutorials we found were for trivial domains, we had a lot of domain logic as well as years of inherited corner cases and brain overloads camouflaged as code. That obviously didn't stop us from giving DDD a try.

We have tried DDD in a real world legacy monolith and survived. Now we're here to tell the tale.

In this talk, we share our own experiences from using DDD inside a monolith, as well as lack of DDD, and you will learn to avoid the mistakes we made and how to repeat our success factors.

How do you use DDD in your highly complex legacy project? How do you even get started? We'll help you!

See https://2019.boosterconf.no/talks/1216

Transcript

1. Domain driven design in the real world Anne Landro @AnneLandro Mads Opheim @MadsOpheim Booster 2019
2. A project named Lovisa 2
3. What is domain-driven design (DDD)? 3
4. If you need to translate between your code and your customer, you’re not doing DDD 4
5. How did we get started? 5
6. Make it safe 6
7. Forkynning - you have been served 7
8. Ubiquitous language 8
9. One word can have several meanings 9
10. Use your users’ language 10
11. 11 The Deadline For Kunngjøring Is Four Weeks()
12. 12 Properties For Namsmann Mainly Follow The Same Rules as Hovedstevnevitne()
13. 3 ways to fail at naming 13
14. 14 Aktør (Actor) Mottaker av forkynning (Recipient of forkynning)
15. Hastesak vs avgjørelse i midlertidig sikring tatt til følge uten rettsmøte 15
16. Why didn’t we just use hastesak? 16
17. Conscious modelling 17
18. Don’t rewrite your entire system 18
19. One good test can make bad code understandable 19
20. 20 courtWillDoSeveralAttemptsToContactYou: writeALetterToSend() sendLetterByMail() waitTwoWeeksForAnswer() sendThePoliceToYourDoorToGiveYouTheLetterInPerson() assertThatYouHaveConfirmedToReceiveTheLetter()
21. What about the technical domain? 21
23. Different domains, different languages 23
25. Different things are different 25
28. 28 More complex is better?
30. Mindsets to adopt 30
31. Key takeaways • Use the users’ language • Model the reality • Event storming 31
32. DDD worked on our legacy monolith - what’s your excuse? 32
33. Thank you! @MadsOpheim mads.opheim@computas.com @AnneLandro anne.landro@computas.com 33