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

Tackling complex domains: strategies and patterns

Tackling complex domains: strategies and patterns

Most web applications are dealing with non-trivial tasks, such as calculating prices and billing items, booking reservations, etc. Each of these topics is a complex domain: there are many requirements, some business rules, and many interactions to handle. If the software project is not organized, architectured, complexity goes up and the project quickly derails.

This talk has a look at how we move from requirements to software architecture, and then to code. We will discuss strategies to discover a domain, tools to model it and share it with the team, and finally patterns to express it in code.
Amongst those, there are Domain-Driven Design and Enterprise Architecture. Though they can't be fully applied every time, I believe some of their techniques can be useful every day. And every developer could benefit from tools to get a better understanding of what they are coding and how to express their intention in their code.

Romaric Drigon

August 04, 2020
Tweet

More Decks by Romaric Drigon

Other Decks in Programming

Transcript

  1. Tackling complex domains:
    strategies and pa,erns
    Romaric Drigon @ Webmardi, Lausanne, 04.08.2020

    View full-size slide

  2. Romaric Drigon
    So#ware engineer @ ASIT

    View full-size slide

  3. Most web apps deals
    with non-trivial tasks
    Online booking, e-commerce
    with stock management and invoicing...

    View full-size slide

  4. How to code those?

    Easily!
    - what to code? specifica/on?

    Bug free
    - tests? edge cases?

    Easy to maintain
    - long life)me

    View full-size slide

  5. Let me tell you a story:
    developping an ERP so0ware

    View full-size slide

  6. Including many modules

    View full-size slide

  7. This project in numbers
    • 8 developers
    !"""""""
    • 6 months
    • we wrote 59 769 lines of PHP (tests not included)
    • using Symfony framework
    • 584 classes

    View full-size slide

  8. It could have been an horror story!

    View full-size slide

  9. Domain-Driven Design to the rescue

    View full-size slide

  10. What is a domain?
    A sphere of knowledge, influence, or ac6vity. The subject area to
    which the user applies a program is the domain of the so?ware.
    — Eric Evans
    In my project, it was legal case management

    View full-size slide

  11. We want a useful model of that domain
    “With Domain-Driven Design, it’s a model
    of the business domain that ma9ers most.”
    — Vaugh Vernon, Implemen1ng Domain-Driven Design
    So we need to understand the domain, to model it
    and to code this model in our project

    View full-size slide

  12. 1. Understanding the Domain
    What is legal case management?

    View full-size slide

  13. How to discover a domain?
    Get access and discuss with business people,
    for whom you are making the so6ware (users):
    They are stakeholders
    It doesn't work well in closed organiza3ons (silos); with remote
    agencies; or when doing "communica3on-through-specifica3on"

    View full-size slide

  14. Interviews and whiteboard discussions

    View full-size slide

  15. Reviewing wireframes / mockups

    View full-size slide

  16. Drawing workflows

    View full-size slide

  17. Event Storming
    “A method to discover business processes”
    Picture from h-ps:/
    /medium.com/techlabs-emag/what-is-event-
    storming-ed1a0e519fad

    View full-size slide

  18. 2. Expressing the Domain
    How to get the "model" of the Domain?

    View full-size slide

  19. Ubiquitous language

    View full-size slide

  20. “A common, shared, vocabulary,
    where words have a specific and
    well-defined meaning in your applica3on”

    View full-size slide

  21. Bounded Contexts

    View full-size slide

  22. “Divide and conquer”

    View full-size slide

  23. Source : Mar+n Fowler, h2ps:/
    /mar+nfowler.com/bliki/BoundedContext.html

    View full-size slide

  24. Think of Bounded Contexts
    as microservices
    But it does not have to be separate apps:
    bundles, packages, modules, or folders...

    View full-size slide

  25. 3. A "rich" Domain Model
    To capture and code what we learnt

    View full-size slide

  26. Our code should contain
    a Domain Model,
    a set of classes
    describing the business
    ≠ infrastructure code,
    which is dealing with technical details,
    such as database access, e-mail sending...

    View full-size slide

  27. In example
    • inside Drive Bounded Context
    • En##es are objects containing both
    business logic and persisted data
    • we are using an ORM to handle
    database read/write
    • non-persisted objects in Model folder
    Project was using Symfony framework and
    Doctrine ORM

    View full-size slide

  28. Expressive code
    With business logic

    View full-size slide

  29. Anemic model

    View full-size slide

  30. Bloated services

    View full-size slide

  31. Some business rules are not easy to code.
    • many branches (complexity)
    • hard to follow
    • process spans over several days
    • etc.
    Then we need help more specifically with
    how to structure our code

    View full-size slide

  32. 4. Architectural pa/erns
    To structure something complex

    View full-size slide

  33. Events: dispatcher pa,ern
    Our code throw events, listeners react to those
    • allows to decouple
    • avoids duplica0on
    • listeners tend to be small classes
    • easier to test

    View full-size slide

  34. Watch out for the mess, though

    View full-size slide

  35. Workflow
    Schema up there is dumped from Symfony workflow component

    View full-size slide

  36. Commands bus
    PHP implementa,ons I recommend are Tac,cian, or Symfony Messenger

    View full-size slide

  37. 5. Design pa,erns
    To simplify a piece of code

    View full-size slide

  38. It worked out pre,y well
    The part of the project I contributed to
    was successful:
    • Major deadlines were met
    • Team could integrate new developers
    easily
    • First version was released, and
    development of new features con;nues

    View full-size slide

  39. Feedback over strategies
    1. Meet business people: great, but not always easy
    2. Use a common vocabulary
    • Ubiquitous Language
    3. Split big apps into smaller pieces
    • Bounded Contexts
    4. Code a rich Domain Model
    • business classes are the crown jewels of your app

    View full-size slide

  40. Feedback over pa-erns
    • + makes code easier to understand
    • + allows to decouple sub-units:
    • productivity++
    • facilitates team work (less Git conflicts)
    • + usually easier to test
    • - requires more explana;on at the beginning

    View full-size slide

  41. Thank you for your a,en.on!
    h,ps:/
    /romaricdrigon.github.io/

    View full-size slide