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

Riding the elevator: Domain-driven Design in the Penthouse

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. Riding the elevator:



    Domain Driven Design


    in the Penthouse
    MICHAEL PLÖD
    FELLOW

    View Slide

  2. 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

    View Slide

  3. https:/
    /architectelevator.com/

    View Slide

  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“

    View Slide

  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?

    View Slide

  6. DDD Topics
    •Domain Modeling


    •Identifying boundaries


    •Shared understanding between domain
    experts and developers


    •Categorizing Subdomains


    •Context Mapping


    •Iterative design work

    View Slide

  7. How could they complement each other?

    View Slide

  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“

    View Slide

  9. „We start an agile transformation,

    how can we do modeling, design and
    requirements engineering in this scenario?“

    View Slide

  10. Check out DDD-CREW on GitHub
    https://github.com/ddd-crew

    View Slide

  11. https://github.com/ddd-crew/ddd-starter-modelling-process

    View Slide

  12. Key Message for the penthouse:


    Domain Driven Design is iterative
    and based on continuous
    improvement / learning

    View Slide

  13. Let’s check the agile manifesto against the cultural
    ideas of Domain Driven Design

    View Slide

  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

    View Slide

  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.

    View Slide

  16. Key Message for the penthouse:


    Domain Driven Design thrives in an
    agile environment and suffers
    heavily in a waterfall

    View Slide

  17. „We are business driven everyone knows
    this“

    View Slide

  18. https://github.com/ddd-crew/ddd-starter-modelling-process

    View Slide

  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…

    View Slide

  20. View Slide

  21. What is the

    purpose of digitalization

    from a business perspective

    View Slide

  22. Purposes of digitalization
    Digitalization
    Improve an existing business
    model with tech
    Create a whole new business
    (model) enabled by tech

    View Slide

  23. The words business & tech appeared together in both
    purposes
    Did you realize?

    View Slide

  24. „Let’s introduce DevOps!“

    View Slide

  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

    View Slide

  26. Are about you design it, you build it and you run it
    Message to the Penthouse:


    Cross-functional teams

    View Slide

  27. Source: https://amplitude.com/blog/journey-to-product-teams-infographic

    View Slide

  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

    View Slide

  29. https://github.com/ddd-crew/ddd-starter-modelling-process

    View Slide

  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

    View Slide

  31. View Slide

  32. How the business names things
    TV
    Window
    Chair
    Trolley
    Painting
    Desk
    What we see in code
    TransparencyFactory
    RollableStuffContainer
    EntertainmentProviderSingleton
    DecoratorImpl
    RestProvider
    WorkEnablementDevice

    View Slide

  33. Developers

    Architects
    Requirements

    Engineers
    Business

    Domain

    Experts

    View Slide

  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

    View Slide

  35. What should you propose to
    the penthouse?

    View Slide

  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

    View Slide

  37. Are there already Design Thinking initiatives in the
    business?


    Is your organization prepared for direct collaboration?
    Questions for the penthouse

    View Slide

  38. „We want to become a tech-enabled


    product organization“

    View Slide

  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


    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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/

    View Slide

  49. https://github.com/ddd-crew/ddd-starter-modelling-process

    View Slide

  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

    View Slide

  51. „Let’s go all in on SaaS and the cloud“

    View Slide

  52. https://github.com/ddd-crew/ddd-starter-modelling-process

    View Slide

  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

    View Slide

  54. https://github.com/ddd-crew/core-domain-charts

    View Slide

  55. „We are a bank, not a software shop“
    I really heard that quote from a C-Level person … I’m not kidding

    View Slide

  56. Some explicit questions for the penthouse

    View Slide

  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

    View Slide

  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

    View 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

    View Slide

  60. „We want agile and cross-functional teams
    which are autonomous and which can
    deliver fast“

    View Slide

  61. https://github.com/ddd-crew/ddd-starter-modelling-process

    View Slide

  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/

    View Slide

  63. But don’t aim for ultimate perfection
    The bigger the alignment between
    problem and solution space, the better

    View Slide

  64. Bounded Context
    A Bounded Context is a boundary for a
    model expressed in a consistent language
    tailored around a speci
    f
    ic purpose

    View Slide

  65. https://github.com/ddd-crew/ddd-starter-modelling-process

    View Slide

  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

    View Slide

  67. https://github.com/ddd-crew/ddd-starter-modelling-process

    View Slide

  68. 68
    The

    Bounded Context

    is a


    team
    f
    irst
    boundary

    View Slide

  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

    View Slide

  70. We need good
    boundaries in which
    teams can achieve

    Autonomy


    Mastery


    Purpose

    View Slide

  71. View Slide

  72. Strategic Domain
    Driven Design

    also has a technique
    to visualize
    sociotechnical
    relationships:


    CONTEXT MAPS

    View Slide

  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 ✅

    View Slide

  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

    View Slide

  75. „Great, Domain Driven Design sounds like a
    silver bullet that solves everything.


    Let’s start a DDD-initiative“
    🤯 😱
    Noooooooo!

    View Slide

  76. SORRY!


    Nothing is this talk was a silver-bullet


    You have to
    f
    ind out what works for you

    View Slide

  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: [email protected]


    Socials: @[email protected]


    LinkedIn: https://www.linkedin.com/in/michael-ploed/

    View Slide