Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Domain driven design in the real world

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

Mads Opheim

March 14, 2019
Tweet

More Decks by Mads Opheim

Other Decks in Technology

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. 22

    View Slide

  23. Different domains,
    different languages
    23

    View Slide

  24. 24

    View Slide

  25. Different things are
    different
    25

    View Slide

  26. View Slide

  27. 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
    [email protected]
    @AnneLandro
    [email protected]
    33

    View Slide