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
   

   View Slide

2. A project named
   Lovisa
   2
   

   View Slide

3. What is domain-driven
   design (DDD)?
   3
   

   View Slide

4. If you need to
   translate between
   your code and your
   customer, you’re not
   doing DDD
   4
   

   View Slide

5. How did we get
   started?
   5
   

   View Slide

6. Make it safe
   6
   

   View Slide

7. Forkynning - you have
   been served
   7
   

   View Slide

8. Ubiquitous language
   8
   

   View Slide

9. One word can have
   several meanings
   9
   

   View Slide

10. Use your users’
    language
    10
    

    View Slide

11. 11
    The Deadline For
    Kunngjøring Is Four Weeks()
    

    View Slide

12. 12
    Properties For Namsmann
    Mainly Follow The Same
    Rules as Hovedstevnevitne()
    

    View Slide

13. 3 ways to fail at
    naming
    13
    

    View Slide

14. 14
    Aktør
    (Actor)
    Mottaker av
    forkynning
    (Recipient of
    forkynning)
    

    View Slide

15. Hastesak
    vs
    avgjørelse i midlertidig sikring tatt
    til følge uten rettsmøte
    15
    

    View Slide

16. Why didn’t we just use
    hastesak?
    16
    

    View Slide

17. Conscious modelling
    17
    

    View Slide

18. Don’t rewrite your
    entire system
    18
    

    View Slide

19. One good test can
    make bad code
    understandable
    19
    

    View Slide

20. 20
    courtWillDoSeveralAttemptsToContactYou:
    writeALetterToSend()
    sendLetterByMail()
    waitTwoWeeksForAnswer()
    sendThePoliceToYourDoorToGiveYouTheLetterInPerson()
    assertThatYouHaveConfirmedToReceiveTheLetter()
    

    View Slide

21. What about the
    technical domain?
    21
    

    View Slide

22. View Slide

23. Different domains,
    different languages
    23
    

    View Slide

24. View Slide

25. Different things are
    different
    25
    

    View Slide

26. View Slide

27. View Slide

28. 28
    More complex is
    better?
    

    View Slide

29. View Slide

30. Mindsets to adopt
    30
    

    View Slide

31. Key takeaways
    ● Use the users’ language
    ● Model the reality
    ● Event storming
    31
    

    View Slide

32. DDD worked on our
    legacy monolith -
    what’s your excuse?
    32
    

    View Slide

33. Thank you!
    @MadsOpheim
    mads.opheim@computas.com
    @AnneLandro
    anne.landro@computas.com
    33
    

    View Slide