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

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 “If the architecture of the system and the architecture

    of the organization are at odds, the architecture of the organization wins” —Ruth Malan
  2. @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
  3. @kenny_baas Label 1 Website Label 2 Website API GATEWAY Label

    3 Website Business 3 Business 2 Business 1 CRM Datawarehouse Data API
  4. @kenny_baas [In our study at Thoughtworks we found] work takes

    an order of magnitude longer when it leaves a team. — James Lewis (@boicy)
  5. @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
  6. @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
  7. @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
  8. @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
  9. @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
  10. @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
  11. @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)
  12. @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
  13. @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!
  14. @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/