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.

Transcript

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

   View Slide

2. Romaric Drigon
   So#ware engineer @ ASIT
   

   View Slide

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

   View Slide

4. How to code those?
   ☑
   Easily!
   - what to code? specifica/on?
   ☑
   Bug free
   - tests? edge cases?
   ☑
   Easy to maintain
   - long life)me
   

   View Slide

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

   View Slide

6. Including many modules
   

   View 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 Slide

8. It could have been an horror story!
   

   View Slide

9. Domain-Driven Design to the rescue
   

   View 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 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 Slide

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

    View 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 Slide

14. Interviews and whiteboard discussions
    

    View Slide

15. Reviewing wireframes / mockups
    

    View Slide

16. Drawing workflows
    

    View Slide

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

    View Slide

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

    View Slide

19. Ubiquitous language
    

    View Slide

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

    View Slide

21. View Slide

22. Bounded Contexts
    

    View Slide

23. “Divide and conquer”
    

    View Slide

24. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

28. 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 Slide

29. 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 Slide

30. Expressive code
    With business logic
    

    View Slide

31. Anemic model
    

    View Slide

32. Bloated services
    

    View Slide

33. 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 Slide

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

    View Slide

35. View Slide

36. 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 Slide

37. Watch out for the mess, though
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

41. View Slide

42. Final word
    

    View Slide

43. 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 Slide

44. 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 Slide

45. 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 Slide

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

    View Slide