$30 off During Our Annual Pro Sale. View Details »

Towards Autonomously aligned teams with Domain-Driven Design @ Tweakers conf 2022

Towards Autonomously aligned teams with Domain-Driven Design @ Tweakers conf 2022

I’ve been involved in several transformations over the years, from DevOps to Digital to Agile. These transformations typically focus on transitioning people into near-autonomous teams of no more than eight people who will work in an agile manner. Every company I’ve worked for asks the same questions at these transformations: How do we divide the current software between the teams, and how do we align these teams to our business architecture?

To address these questions, companies request my help to design microservices using a Domain-Driven Design (DDD) approach. This approach makes it easier to distribute the software between teams based on identified boundaries, called “bounded contexts.” While I believe enterprises involved in an Agile transformation need at least a Domain-Driven Design approach to create autonomous aligned teams with a loosely-coupled architecture, this process presents unique challenges. In this talk I will present my experience report, I share my experience over a period of six months using DDD to transition a financial enterprise towards Agile autonomous teams.

Kenny Baas-Schwegler

June 23, 2022
Tweet

More Decks by Kenny Baas-Schwegler

Other Decks in Technology

Transcript

  1. @kenny_baas
    Towards Autonomous Aligned Teams
    with Domain-Driven Design
    Kenny Baas-Schwegler

    View Slide

  2. @kenny_baas

    View Slide

  3. @kenny_baas
    “If the architecture of the system
    and the architecture of the organization are at odds,
    the architecture of the organization wins”
    —Ruth Malan

    View Slide

  4. @kenny_baas

    View Slide

  5. @kenny_baas

    View Slide

  6. @kenny_baas
    Any organization that designs a system
    (defined more broadly here than just information systems)
    will inevitably produce a design whose structure
    is a copy of the organization's communication structure.
    — Mel Conway

    View Slide

  7. @kenny_baas

    View Slide

  8. @kenny_baas
    Label 1
    Website
    Label 2
    Website
    API
    GATEWAY
    Label 3
    Website
    Business 3
    Business 2
    Business 1 CRM
    Datawarehouse
    Data API

    View Slide

  9. @kenny_baas
    [In our study at Thoughtworks we found] work
    takes an order of magnitude longer when it
    leaves a team.
    — James Lewis (@boicy)

    View Slide

  10. @kenny_baas
    “A loosely coupled software architecture
    and org structure to match” is a key
    predictor of:
    1. Continuous Delivery Performance
    2. Ability to scale org and increase
    performance linearly

    View Slide

  11. Order Payment Packaging

    View Slide

  12. @kenny_baas

    View Slide

  13. @kenny_baas

    View Slide

  14. @kenny_baas
    https://www.martinfowler.com/articles/microservices.html

    View Slide

  15. @kenny_baas

    View Slide

  16. @kenny_baas
    To communicate effectively, the code must be based on the
    same language used to write the requirements
    - the same language that the developers speak
    with each other and with domain experts
    - Eric Evans

    View Slide

  17. @kenny_baas
    https://www.huffingtonpost.co.uk/entry/american-tweets-about-great-british-bake-off_uk_61733eaee4b03072d6f6d012

    View Slide

  18. @kenny_baas

    View Slide

  19. @kenny_baas
    We all know or should know that language is fluid, liquid, subject to the
    whims of the people. Language evolves, as it should. Because language
    changes to accommodate new users, the older users resist and complain.
    http://tednellen.blogspot.com/2013/04/language-is-fluid.html

    View Slide

  20. @kenny_baas
    It is not the domain experts knowledge
    that goes to production, it is the
    assumption of the developers
    that goes to production
    - Alberto Brandolini

    View Slide

  21. @kenny_baas
    Instead of one canonical language,
    create multiple bounded languages

    View Slide

  22. @kenny_baas
    Business
    Architects
    Developers

    View Slide

  23. @kenny_baas

    View Slide

  24. @kenny_baas

    View Slide

  25. @kenny_baas

    View Slide

  26. @kenny_baas
    A straight line between 2 points
    corresponds to a compass direction in
    reality..

    View Slide

  27. @kenny_baas
    A straight line between 2 points corresponds to
    a compass direction in reality..
    • Except for points located in Greenland
    • Except for points located in Africa

    View Slide

  28. @kenny_baas
    A model is a simplified representation of a thing
    or phenomenon that intentionally emphasizes
    certain aspects while ignoring others.
    Abstraction with a specific use in mind.
    — Rebecca Wirfs-Brock

    View Slide

  29. @kenny_baas
    Business
    Architects
    Developers

    View Slide

  30. @kenny_baas
    Stop communicating business change
    in system boundaries
    (unit of deployment like in microservices, monolith)
    Start communicating business change in
    contextual boundaries that form the bounded context
    (purpose, need, responsibility)

    View Slide

  31. @kenny_baas

    View Slide

  32. @kenny_baas

    View Slide

  33. @kenny_baas

    View Slide

  34. @kenny_baas

    View Slide

  35. @kenny_baas
    Any organization that designs a system
    (defined more broadly here than just information systems)
    will inevitably produce a design whose structure
    is a copy of the organization's communication structure.
    — Mel Conway

    View Slide

  36. @kenny_baas

    View Slide

  37. @kenny_baas

    View Slide

  38. @kenny_baas

    View Slide

  39. @kenny_baas

    View Slide

  40. @kenny_baas

    View Slide

  41. @kenny_baas https://www.eventstorming.com/

    View Slide

  42. @kenny_baas https://www.eventstorming.com/
    Mortgage
    request
    received
    Mortgage
    application
    passed
    Tender
    signed
    Declaration
    rejected

    View Slide

  43. @kenny_baas

    View Slide

  44. @kenny_baas

    View Slide

  45. @kenny_baas
    https://www.eventstorming.com/

    View Slide

  46. @kenny_baas
    https://www.eventstorming.com/

    View Slide

  47. @kenny_baas

    View Slide

  48. @kenny_baas
    What influences our grouping of the domains?
    ● Customers
    ● Resources
    ● People
    ● Team cognitive load
    ● Cohesion of change
    ● Change rate
    ● Culture
    ● Business strategy and their value streams
    ● Software architecture
    ● Organisation structure
    ● Knowledge & Practice
    ● …..
    ● Aka Contextual!

    View Slide

  49. @kenny_baas

    View Slide

  50. @kenny_baas
    Using collaborative modelling to build a
    shared understanding of your domain and use it to
    guide your design _is_ the philosophy behind DDD
    though. The rest is principles, patterns, and practices.
    — Mathias Verraes
    https://verraes.net/2021/09/what-is-domain-driven-design-ddd/

    View Slide

  51. @kenny_baas

    View Slide

  52. @kenny_baas
    https://www.martinfowler.com/articles/microservices.html

    View Slide

  53. @kenny_baas

    View Slide

  54. @kenny_baas
    Domain-Driven Design enables teams to have agency

    View Slide

  55. @kenny_baas
    #CatTax
    @kenny_baas
    Baasie.com
    xebia.com/blog/author/kbaas/
    https://speakerdeck.com/baasie
    Agile Alliance report:
    https://www.agilealliance.org/resources/experience-reports/towards-auton
    omous-aligned-teams-with-domain-driven-design/
    https://virtualddd.com/

    View Slide