Riding the elevator: Domain-driven Design in the Penthouse

In his book The Software Architect Elevator Gregor Hohpe uses the analogy of an elevator in a high building for the daily work which software architects should be doing: They are supposed to talk to folks who build and maintain stuff in the engine room but also make sure that the managment which is residing on the penthouse floors understand and gain interest in what is happening in the engine room.

In my talk I will build upon Gregors ideas and show you how you can leverage ideas from Domain Driven Design in this daunting communication tasks. But rest assured: I will not only present the obvious strategic Domain Drivend Design elements like core / supporting / generic subdomains here. We will go deeper and explore links to other initiatives in an org like DevOps, Agile and / org Design Thinking as well which are of interest for the leadership of an organization.

We as a community should get better at this topic because Domain Driven Design needs a healthy, blame free and safe environment in order to flourish and this environment needs to be established and lived by the leadership folks.

PS: The talk idea and usage of Gregors elevator analogy have been approved by Gregor

Transcript

1. Riding the elevator: 
 Domain Driven Design in the Penthouse MICHAEL PLÖD FELLOW
2. Michael Plöd Fellow at INNOQ Mastodon (or Twitter): @bitboss@mastodon.social LinkedIn: https://www.linkedin.com/in/michael-ploed/ Current consulting topics: • Domain-Driven Design • Team Topologies • Transformation from IT Delivery to digital product orgs Regular speaker at (inter-)national conferences and author of a book + various articles
3. https:/ /architectelevator.com/
4. Modern architects align organization and technology, reduce friction, and chart transformation journeys. In addition to working with UML and architecture styles, such architects ride the Architect Elevator from the penthouse, where the business strategy is set, to the engine room, where the enabling technologies are implemented. They shun popular buzzwords in favor of a clear strategy de f ined by conscious decision making. Gregor Hohpe Author of „The Software Architect Elevator“
5. Topics in the penthouse •Make or Buy decisions •How do I make my org more agile? •How do I structure my teams? •How can we transform our existing legacy software (to the cloud)? •How can we become a product-driven org? •Digitalization •How do we differentiate in a digital market? •How can our teams become more autonomous?
6. DDD Topics •Domain Modeling •Identifying boundaries •Shared understanding between domain experts and developers •Categorizing Subdomains •Context Mapping •Iterative design work
7. How could they complement each other?
8. Modern architects align organization and technology, reduce friction, and chart transformation journeys. In addition to working with UML and architecture styles, such architects ride the Architect Elevator from the penthouse, where the business strategy is set, to the engine room, where the enabling technologies are implemented. They shun popular buzzwords in favor of a clear strategy de f ined by conscious decision making. Gregor Hohpe Author of „The Software Architect Elevator“
9. „We start an agile transformation, 
 how can we do modeling, design and requirements engineering in this scenario?“
10. Check out DDD-CREW on GitHub https://github.com/ddd-crew
11. https://github.com/ddd-crew/ddd-starter-modelling-process
12. Key Message for the penthouse: Domain Driven Design is iterative and based on continuous improvement / learning
13. Let’s check the agile manifesto against the cultural ideas of Domain Driven Design
14. Domain Driven Design is all about 
 continuous learning through direct 
 customer feedback Changing requirements may come from 
 new insights and learnings. Something 
 we appreciate in Domain Driven Design This principle is not addressed directly by 
 Domain Driven Design but most folks in 
 the community agree with it This is what Domain Driven Design 
 is all about on a collaborative level Modern Domain Driven Design talks a 
 lot about trust and safe environments. 
 So: yes, there is a perfect f it
15. This is 100% a core idea / principle 
 in Domain Driven Design Not directly addressed but appreciated Domain Driven Design does not address 
 concepts like pace but most experts will 
 agree that this principle is a good idea There is a dedicated chapter in the 
 blue book by Eric Evans: Supple Design DDD does not talk about simplicity but 
 about addressing / managing complexity This is heavily addressed in modern 
 sociotechnical Domain Driven Design Domain Driven Design does not mention 
 retrospectives or team improvements 
 but many experts fully agree with this.
16. Key Message for the penthouse: Domain Driven Design thrives in an agile environment and suffers heavily in a waterfall
17. „We are business driven everyone knows this“
18. https://github.com/ddd-crew/ddd-starter-modelling-process
19. Do your architects understand the business model of their products? Is there a shared understanding between various stakeholders regarding the business model? Questions for the penthouse…
21. What is the 
 purpose of digitalization 
 from a business perspective
22. Purposes of digitalization Digitalization Improve an existing business model with tech Create a whole new business (model) enabled by tech
23. The words business & tech appeared together in both purposes Did you realize?
24. „Let’s introduce DevOps!“
25. You build it, you run it Business 
 Domain 
 Experts Developers 
 Architects Operations 
 DDD Dev 
 Ops You design it, you build it and you run it
26. Are about you design it, you build it and you run it Message to the Penthouse: Cross-functional teams
27. Source: https://amplitude.com/blog/journey-to-product-teams-infographic
28. Source: https://amplitude.com/blog/journey-to-product-teams-infographic Moving the responsibilities 
 to the left requires developers 
 to understand the business 
 as well as the business to 
 understand tech
29. https://github.com/ddd-crew/ddd-starter-modelling-process
30. „It is not the domain experts knowledge that goes into production, it is the assumption of the developers that goes into production” 30 Alberto Brandolini Inventor of EventStorming
32. How the business names things TV Window Chair Trolley Painting Desk What we see in code TransparencyFactory RollableStuffContainer EntertainmentProviderSingleton DecoratorImpl RestProvider WorkEnablementDevice
33. Developers 
 Architects Requirements 
 Engineers Business 
 Domain 
 Experts
34. Source: https://medium.com/agileinsider/what-we-learned-from-our-survey-of-550-product-managers-and-leaders-79340126ccab "If you're just using your engineers to code, you're only getting about half their value.“ Marty Cagan
35. What should you propose to the penthouse?
36. Collaborative Modeling Image for example mapping taken from: https://openpracticelibrary.com/practice/example-mapping/ 
 Image for user story mapping taken from: https://www.hanssamios.com/dokuwiki/how_do_we_build_and_maintain_context_when_all_we_have_is_a_backlog_list
37. Are there already Design Thinking initiatives in the business? Is your organization prepared for direct collaboration? Questions for the penthouse
38. „We want to become a tech-enabled product organization“
39. Shift from Projects to Products Tech-enabled Organizations •Tech is core strategic asset in product and not a cost center •No feature factories •Strong aim to insourcing of development of functionality which is core to the business
40. 40 Innovation Cycles Teams Market Look for signals from Great User 
 Experience Expects Software Architecture Is enabled by Is developed by Source: https://www.ntcoding.com
41. „the key to incremental architecture is to build on a framework that can accommodate change... that framework is the domain.... By modeling the domain, you can more easily handle changes to the domain“ Allen Holub https:/ /holub.com
42. 42 Innovation Cycles Teams Market Look for signals from Great User 
 Experience Expects Software Architecture Is enabled by Is developed by Business 
 Domain Should be 
 a model of Source: https://www.ntcoding.com
43. 43 “A loosely coupled software architecture and org structure to match” is a key predictor of: •Continuous Delivery Performance •Ability to scale organization and increase performance linearly
44. 44 Innovation Cycles Teams Market Look for signals from Great User 
 Experience Expects Software Architecture Is enabled by Is developed by Business 
 Domain Should be 
 a model of Should be 
 aligned with Source: https://www.ntcoding.com
45. 45 Strategic DDD helps with the alignment of the business domain with software architecture and teams Teams Software Architecture Business 
 Domain Should be 
 a model of Should be 
 aligned with Source: https://www.ntcoding.com
46. „Product thinking is the journey from the problem space of the users to the solution space of the business. The goal of this journey is to reduce the gap between users and the business.” Naren Katakam
47. Problem vs Solution Space Strategic Design starts with the problem space, which represents the business architecture and which includes problem domains and (categorized) subdomains. The solution space represents the software architecture and contains the bounded context. There must be an overlap between the two. Problem Space Solution Space Domain & Subdomain Bounded 
 Context & Tactical 
 Design
48. „Domains live in the problem space. They are how an organization perceives its areas of activity and expertise.“ Mathias Verraes and Rebecca Wirfs-Brock Quote from „Splitting a Domain Across Multiple Bounded Contexts“ https://verraes.net/2021/06/split-domain-across-bounded-contexts/
49. https://github.com/ddd-crew/ddd-starter-modelling-process
50. Subdomains •Each problem domain can contain some subdomains •These subdomains are lower level business capabilities than the ones of a domain •The identi f ication of subdomains is usually performed by collaborative modeling within an integrated teams Domain 
 Experts Dev 
 Team Cross-skill collaboration Hands-on modeling Problem Domain help to identify Subdomain A Subdomain B Subdomain C Subdomain D
51. „Let’s go all in on SaaS and the cloud“
52. https://github.com/ddd-crew/ddd-starter-modelling-process
53. Categories for Subdomains in DDD Category Core 
 (Sub)domain • Most important subdomains which are the heart of an organization’s business • Mid- to long term differentiation against competitors • Heuristic: high differentiation and high complexity Supporting Subdomain • Vital for the operating of core (sub)domains • Lack of strategic relevance with regards to competition • Heuristic: everything that is between core and generic Generic Subdomain • Needed functionality, not a lot of passion for it at all in terms of business ambitions • „We need some solution of problem x“ • Heuristic: low differentiation, no matter how complex
54. https://github.com/ddd-crew/core-domain-charts
55. „We are a bank, not a software shop“ I really heard that quote from a C-Level person … I’m not kidding
56. Some explicit questions for the penthouse
57. How are your teams staffed? Internal Internal External External Internal •This is a highly critical situation •You want to own everything in your core domains •External teams should be the exception in those areas •All T Complexity Differentiation Mixed
58. Better: Internal Internal External External Internal Complexity Differentiation Mixed •Follow a clear staf f ing strategy with regards to domain classi f ications •Core: only really good internal teams •Supporting: External ok, areas of high differentiation may work with mixed teams •Generic: see next slide
59. Make or Buy Simple SaaS SaaS w. extensions Self written SAP •Don’t write your own software in non differentiating areas •The categories may change over time. Something that was differentiating 15 years ago may be generic nowadays •Mind this when modernizing your IT Complexity Differentiation Self written Simple SaaS SAP Self written
60. „We want agile and cross-functional teams which are autonomous and which can deliver fast“
61. https://github.com/ddd-crew/ddd-starter-modelling-process
62. „Domains live in the problem space. They are how an organization perceives its areas of activity and expertise. Bounded Contexts are part of the solution space; they are deliberate design choices. As a systems designer, you choose these boundaries to manage the understandability of the system, by using different models to solve different aspects of the domain.“ Mathias Verraes and Rebecca Wirfs-Brock Quote from „Splitting a Domain Across Multiple Bounded Contexts“ https://verraes.net/2021/06/split-domain-across-bounded-contexts/
63. But don’t aim for ultimate perfection The bigger the alignment between problem and solution space, the better
64. Bounded Context A Bounded Context is a boundary for a model expressed in a consistent language tailored around a speci f ic purpose
65. https://github.com/ddd-crew/ddd-starter-modelling-process
66. 66 Bounded Context Design Canvas The canvas guides you through the process of designing a bounded context by requiring you to consider and make choices about the key elements of its design, from naming to responsibilities, to its public interface and dependencies. Source: https://github.com/ddd-crew/bounded-context-canvas
67. https://github.com/ddd-crew/ddd-starter-modelling-process
68. 68 The 
 Bounded Context 
 is a team f irst boundary
69. Mind the COGNITIVE LOAD of the team which is responsible for the bounded context Learning and mastering domain complexity Conducting experiments / Learning Delivering high 
 value software
70. We need good boundaries in which teams can achieve 
 Autonomy Mastery Purpose
72. Strategic Domain Driven Design 
 also has a technique to visualize sociotechnical relationships: CONTEXT MAPS
73. 73 The patterns address various aspects Team 
 Relationships Model 
 Propagation API / „technical“ Open-host Service (✅) ✅ Anticorruption Layer ✅ Conformist ✅ Shared Kernel ✅ (✅) Partnership ✅ Customer-Supplier ✅ Separate Ways ✅ (✅) Published Language ✅ (✅) Big Ball Of Mud ✅
74. 74 Mind team communication Low 
 communication bandwith High 
 communication bandwith Shared Kernel Customer / Supplier Conformist Anticorruption Layer Separate Ways Open / Host Service Published Language Team Communication
75. „Great, Domain Driven Design sounds like a silver bullet that solves everything. Let’s start a DDD-initiative“ 🤯 😱 Noooooooo!
76. SORRY! Nothing is this talk was a silver-bullet You have to f ind out what works for you
77. Krischerstr. 100 40789 Monheim +49 2173 3366-0 Ohlauer Str. 43 
 10999 Berlin 
 Ludwigstr. 180E 
 63067 Offenbach 
 Kreuzstr. 16 
 80331 München 
 Hermannstrasse 13 
 20095 Hamburg 
 Erftstr. 15-17 50672 Köln 
 Königstorgraben 11 90402 Nürnberg innoQ Deutschland GmbH www.innoq.com Thank you! Michael Plöd E-Mail: michael.ploed@innoq.com Socials: @bitboss@mastodon.social LinkedIn: https://www.linkedin.com/in/michael-ploed/