Pro Yearly is on sale from $80 to $50! »

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.

88a681988c6744a099be88084dedb545?s=128

Romaric Drigon

August 04, 2020
Tweet

Transcript

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

    Lausanne, 04.08.2020
  2. Romaric Drigon So#ware engineer @ ASIT

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

    with stock management and invoicing...
  4. How to code those? ☑ Easily! - what to code?

    specifica/on? ☑ Bug free - tests? edge cases? ☑ Easy to maintain - long life)me
  5. Let me tell you a story: developping an ERP so0ware

  6. Including many modules

  7. This project in numbers • 8 developers !""""""" • 6

    months • we wrote 59 769 lines of PHP (tests not included) • using Symfony framework • 584 classes
  8. It could have been an horror story!

  9. Domain-Driven Design to the rescue

  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
  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
  12. 1. Understanding the Domain What is legal case management?

  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"
  14. Interviews and whiteboard discussions

  15. Reviewing wireframes / mockups

  16. Drawing workflows

  17. Event Storming “A method to discover business processes” Picture from

    h-ps:/ /medium.com/techlabs-emag/what-is-event- storming-ed1a0e519fad
  18. 2. Expressing the Domain How to get the "model" of

    the Domain?
  19. Ubiquitous language

  20. “A common, shared, vocabulary, where words have a specific and

    well-defined meaning in your applica3on”
  21. None
  22. Bounded Contexts

  23. “Divide and conquer”

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

  26. Think of Bounded Contexts as microservices But it does not

    have to be separate apps: bundles, packages, modules, or folders...
  27. 3. A "rich" Domain Model To capture and code what

    we learnt
  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...
  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
  30. Expressive code With business logic

  31. Anemic model

  32. Bloated services

  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
  34. 4. Architectural pa/erns To structure something complex

  35. None
  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
  37. Watch out for the mess, though

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

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

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

  41. None
  42. Final word

  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
  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
  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
  46. Thank you for your a,en.on! h,ps:/ /romaricdrigon.github.io/