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.

Transcript

1. @kenny_baas Towards Autonomous Aligned Teams with Domain-Driven Design Kenny Baas-Schwegler
2. @kenny_baas
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
4. @kenny_baas
5. @kenny_baas
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
7. @kenny_baas
8. @kenny_baas Label 1 Website Label 2 Website API GATEWAY Label 3 Website Business 3 Business 2 Business 1 CRM Datawarehouse Data API
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)
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
11. Order Payment Packaging
12. @kenny_baas
13. @kenny_baas
14. @kenny_baas https://www.martinfowler.com/articles/microservices.html
15. @kenny_baas
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
17. @kenny_baas https://www.huffingtonpost.co.uk/entry/american-tweets-about-great-british-bake-off_uk_61733eaee4b03072d6f6d012
18. @kenny_baas
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
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
21. @kenny_baas Instead of one canonical language, create multiple bounded languages
22. @kenny_baas Business Architects Developers
23. @kenny_baas
24. @kenny_baas
25. @kenny_baas
26. @kenny_baas A straight line between 2 points corresponds to a compass direction in reality..
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
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
29. @kenny_baas Business Architects Developers
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)
31. @kenny_baas
32. @kenny_baas
33. @kenny_baas
34. @kenny_baas
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
36. @kenny_baas
37. @kenny_baas
38. @kenny_baas
39. @kenny_baas
40. @kenny_baas
41. @kenny_baas https://www.eventstorming.com/
42. @kenny_baas https://www.eventstorming.com/ Mortgage request received Mortgage application passed Tender signed Declaration rejected
43. @kenny_baas
44. @kenny_baas
45. @kenny_baas https://www.eventstorming.com/
46. @kenny_baas https://www.eventstorming.com/
47. @kenny_baas
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!
49. @kenny_baas
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/
51. @kenny_baas
52. @kenny_baas https://www.martinfowler.com/articles/microservices.html
53. @kenny_baas
54. @kenny_baas Domain-Driven Design enables teams to have agency
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/