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

Riding the elevator: Domain-driven Design in th...

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

Michael Plöd

May 25, 2023
Tweet

More Decks by Michael Plöd

Other Decks in Technology

Transcript

  1. Michael Plöd Fellow at INNOQ Mastodon (or Twitter): @[email protected] 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
  2. 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“
  3. 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?
  4. DDD Topics •Domain Modeling •Identifying boundaries •Shared understanding between domain

    experts and developers •Categorizing Subdomains •Context Mapping •Iterative design work
  5. 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“
  6. „We start an agile transformation, 
 how can we do

    modeling, design and requirements engineering in this scenario?“
  7. Key Message for the penthouse: Domain Driven Design is iterative

    and based on continuous improvement / learning
  8. 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
  9. 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.
  10. Key Message for the penthouse: Domain Driven Design thrives in

    an agile environment and suffers heavily in a waterfall
  11. 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…
  12. Purposes of digitalization Digitalization Improve an existing business model with

    tech Create a whole new business (model) enabled by tech
  13. 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
  14. Are about you design it, you build it and you

    run it Message to the Penthouse: Cross-functional teams
  15. 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
  16. „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
  17. How the business names things TV Window Chair Trolley Painting

    Desk What we see in code TransparencyFactory RollableStuffContainer EntertainmentProviderSingleton DecoratorImpl RestProvider WorkEnablementDevice
  18. 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
  19. Are there already Design Thinking initiatives in the business? Is

    your organization prepared for direct collaboration? Questions for the penthouse
  20. 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
  21. 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
  22. „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
  23. 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
  24. 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
  25. 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
  26. 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
  27. „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
  28. 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
  29. „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/
  30. 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
  31. 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
  32. „We are a bank, not a software shop“ I really

    heard that quote from a C-Level person … I’m not kidding
  33. 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
  34. 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
  35. 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
  36. „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/
  37. But don’t aim for ultimate perfection The bigger the alignment

    between problem and solution space, the better
  38. Bounded Context A Bounded Context is a boundary for a

    model expressed in a consistent language tailored around a speci f ic purpose
  39. 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
  40. 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
  41. Strategic Domain Driven Design 
 also has a technique to

    visualize sociotechnical relationships: CONTEXT MAPS
  42. 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 ✅
  43. 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
  44. „Great, Domain Driven Design sounds like a silver bullet that

    solves everything. Let’s start a DDD-initiative“ 🤯 😱 Noooooooo!
  45. 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: [email protected] Socials: @[email protected] LinkedIn: https://www.linkedin.com/in/michael-ploed/