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

Aligning organization and architecture with strategic DDD

Aligning organization and architecture with strategic DDD

Strategic Domain-driven Design contains many ideas which help teams to find a good alignment of business and software architecture. However, we can also go a step further by matching architecture and teams in the organization. This short talk aims to give you a brief overview of the concepts behind strategic DDD. You will learn about subdomains in the problem space (aka business architecture), bounded contexts in the solution space (software architecture) and how to map those concepts to the teams in the organization with context maps

Michael Plöd

May 04, 2020
Tweet

More Decks by Michael Plöd

Other Decks in Programming

Transcript

  1. Strategic
    Domain
    Driven
    Design
    A n O v e r v i e w b y M i c h a e l P l ö d

    View Slide

  2. 2
    My assuptions / prerequisites
    You have some knowledge about software architecture. Maybe
    even DDD. You don’t need to be an expert.
    I will talk about
    A quick overview about strategic Domain-driven Design. We could
    easily talk over a day on this topic ;-)
    I will NOT talk about
    Any advanced Domain-driven Design stuff. This talk is an overview,
    not a deep dive.

    View Slide

  3. Get my DDD book
    cheaper
    Book Voucher: 7.99 instead of (min) 9.99
    http://leanpub.com/ddd-by-example/c/speakerdeck

    View Slide

  4. 4
    Speaker
    Michael Plöd
    Fellow at INNOQ
    Twitter: @bitboss

    View Slide

  5. 5
    “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

  6. 6
    Domain-driven Design
    is an holisitic approach towards Software
    Architecture which goes beyond technical
    aspects by addressing cultural and
    organizational aspects of a delivery
    organization as well.

    View Slide

  7. How do we solve the
    Problem?
    What Problem do we
    want to solve?

    View Slide

  8. 8
    In order to align the what and the how we
    need communication between the
    business and the IT

    View Slide

  9. Business
    Domain
    Experts
    Developers
    Architects
    ?
    Software Engineering Domain Know-How

    View Slide

  10. What could
    possibly go
    wrong?

    View Slide

  11. How the business names things
    TV
    Window
    Chair
    Trolley
    Painting
    Desk

    View Slide

  12. How the business names things
    TV
    Window
    Chair
    Trolley
    Painting
    Desk
    How developers name things
    TransparencyFactory
    RollableStuffContainer
    EntertainmentProviderSingleton
    DecoratorImpl
    RestProvider
    WorkEnablementDevice

    View Slide

  13. A B
    C
    „Gut, dass wir alle einer Meinung sind!“
    Inspiriert durch Jeff Patton & Luke Barren
    „good, that we all share the same
    opinion“
    Inspired by Jeff Patton and Luke Barren

    View Slide

  14. AB
    C AB
    C
    Inspiriert durch Jeff Patton & Luke Barren
    AB
    C
    „OH!“ „Aha!“ „Gut, dass wir alle einer Meinung sind!“
    „good, that we all
    share the same opinion“
    Inspired by Jeff Patton and Luke Barren

    View Slide

  15. 14
    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
    „what we want to solve“
    Solution Space
    „how we solve something“
    Domain
    Subdomain
    Bounded
    Context

    View Slide

  16. 15
    The bigger the alignment
    between problem and solution
    space, the better
    However, you’ll never be perfect

    View Slide

  17. The domain
    should be the
    heart of a
    system

    View Slide

  18. The domain
    should be the
    heart of a
    system
    Collaborative
    Modelling
    Continuous
    Learning
    Focus on linguistic
    details
    Inclusive
    Environment

    View Slide

  19. 17
    DDD enables Continuous Discovery
    1. De ine a business problem
    2. De ine the desired result
    3. De ine your assumptions
    4. Hypothesis: write your tests irst
    5. Conduct experiments
    6. Consolidate the results
    7. Discard / modify / keep
    8. Repeat
    Ideas
    Measure
    Test
    Build
    Data
    Learn
    Product

    View Slide

  20. 18
    Don’t…
    •use technical modelling tools
    which only the IT is capable of
    •create communication barriers
    between business and IT
    Do…
    •make sure that workshops are
    inclusive for everyone
    •use techniques for collaborative
    modelling

    View Slide

  21. <Design community>>
    Event Storming
    <Design community>>
    Domain Storytelling
    19
    Popular Collaborative Modelling Techniques
    <Development community>>
    Example Mapping
    <community>>
    User Story Mapping

    View Slide

  22. 20
    Problem Domain
    A good understanding of the problem
    domain is key for a decoupled software
    architecture which re lects the business
    •Collaborative Modelling helps in
    shaping a common understanding of
    the problem domain
    Domain
    Experts
    Dev
    Team
    Collaborative Modelling
    Problem Domain
    help to understand

    View Slide

  23. 21
    Subdomains
    •Each problem domain can contain
    some subdomains
    •These subdomains are lower level
    business capabilities than the
    ones of a domain
    •The identi ication of subdomains
    is usually performed by
    collaborative modeling
    •Prefer modern collaborative
    modelling techniques over UML,
    BPNM or other technical tools
    Domain
    Experts
    Dev
    Team
    Collaborative Modelling
    Problem Domain
    help to identify
    Subdomain A Subdomain B
    Subdomain C Subdomain D

    View Slide

  24. 22
    Categories for Subdomains
    Subdomain
    Core (Sub)domain
    • Most important subdomain
    • The heart of an organization’s business
    • Differentiation against competitors
    Supporting Subdomain
    • Vital for the operating of core (sub)domains
    • Lack of strategic relevance with regards to
    competition
    Generic Subdomain
    • Needed functionality, which is not critical at all
    • „We need some solution of problem x“

    View Slide

  25. „Not all parts of
    a system will be
    well designed“
    Eric Evans
    Author (and inventor) of „Domain-Driven
    Design“
    23

    View Slide

  26. 24
    The categorization of subdomains should have an impact on staf ing,
    make or by decisions and IT-procurement
    Core
    (Sub)domain

    In-House development

    Excellent teams with excellent working conditions

    Staf ing strategy should be „insourcing“

    No Near- / Off-Shore development

    No „Custom Off The Shelf“ (COTS / Standard) Software
    Supporting
    Subdomain

    In-House development with external support is possible

    Some Near-Shore development is an option

    „Custom Off The Shelf“ (COTS / Standard Software) products
    that its your processes with minor customizations

    Avoid complete outsourcing and / or major customizations of
    COTS products
    Generic
    Subdomain

    Look of COTS or SaaS Products that get „the task done“

    Staf ing strategy can be „outsourcing“

    Look for cost saving opportunities

    Don’t put your best employees into generic subdomains

    Vendor Management is a key skill in this area
    Cost Focus

    View Slide

  27. 25
    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.
    Solution Space
    Problem Space Domain
    Subdomain
    Bounded
    Context

    View Slide

  28. 25
    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.
    Solution Space
    Problem Space Domain
    Subdomain
    Bounded
    Context

    View Slide

  29. 26
    Centralized models lead to many dependencies

    View Slide

  30. 27
    The language for loan application form may differ
    Loan Application Form
    Loan Applications
    Loan
    Application
    Form
    Scoring
    Applicant
    Scoring Cluster
    Financial
    Situation Scoring
    Cluster
    Applied Credit
    Scoring Cluster
    Credit Decision
    Credit Decision
    Template
    Contracting
    Contract
    Proposal
    Contract

    View Slide

  31. The bounded context is
    a linguistic boundary
    around the meaning of
    a (domain) model
    28

    View Slide

  32. 29
    Each subdomain can have 1..n bounded contexts and each context has
    its own model. In an ideal world you have a 1:1 alignment between the
    both.
    Loan Applications Scoring Credit Decision Contracting
    Credit Sales
    Funnel
    Document
    Check
    Internal Scoring
    Security
    Assessment
    External Scoring
    Credit Decision Contract
    Proposal
    Contract
    Creation
    Credit
    Application
    Applicant
    Document
    Rule
    Clusters
    Securities
    External
    Rating
    Decision
    Template
    Decision
    Hierarchy
    Decision
    Contract
    Proposal
    Contract

    View Slide

  33. 30
    At a later step you may want to re-adjust your business architecture
    expressed as subdomains.
    Credit Sales
    Funnel
    Document
    Check
    Internal Scoring
    Security
    Assessment
    External Scoring
    Credit Decision
    Contract
    Proposal
    Contract
    Creation
    Credit
    Application
    Applicant
    Document
    Rule
    Clusters
    Securities
    External
    Rating
    Decision
    Template
    Decision
    Hierarchy
    Decision
    Contract
    Proposal
    Contract

    View Slide

  34. The decentralization
    of domain models
    with bounded
    contexts has many
    advantages
    The domain models are more explicit and better suited to ful ill
    the capabilities of the bounded context.
    By having specialized models, the teams working with them gain
    a better understanding of the business, the mental model of the
    dev team and the domain experts align and they can deliver
    higher quality results which are more maintainable.
    The decentralization leads to a higher cohesion inside of a
    bounded context and reduces dependencies between teams.
    More work can be done in parallel.
    Due to a higher degree of decoupling between bouded contexts
    the teams working on them can choose different
    implementation options. But: mind macro architecture

    View Slide

  35. 32
    Identi ication
    of bounded contexts
    The identi ication of bounded
    contexts should never be driven from
    one criteria. Instead evaluate a
    weighted set of criteria and invite
    the following stakeholders:
    •Developers / Architects
    •Domain Experts
    •UX Experts
    •Maybe a facilitator

    View Slide

  36. Decomposition of a subdomain in bounded contexts
    Ubiquitous Language
    • Key actors
    • Important verbs
    • Terminology
    Quality Criteria
    • Also known as non-
    functional requirements
    • Look at ISO 25010
    • Examples:
    • Scalability
    • Performance
    • Change frequency
    33
    Capabilities &
    Responsibilities
    • Informational:
    • Queries
    • Reports
    • Actions:
    • Commands / Features
    • Scheduled tasks
    Business Policies
    • Important rules
    • Validations
    • Policies

    View Slide

  37. Also take a look at the amazing Bounded Context Canvas by Nick Tune
    https://medium.com/nick-tune-tech-strategy-blog/bounded-context-canvas-v2-simpli ications-and-additions-229ed35f825f

    View Slide

  38. Decomposition of a subdomain in bounded contexts
    Ubiquitous Language
    • Key actors
    • Important verbs
    • Terminology
    Quality Criteria
    • Also known as non-
    functional requirements
    • Look at ISO 25010
    • Examples:
    • Scalability
    • Performance
    • Change frequency
    35
    Capabilities &
    Responsibilities
    • Informational:
    • Queries
    • Reports
    • Actions:
    • Commands / Features
    • Scheduled tasks
    Business Policies
    • Important rules
    • Validations
    • Policies
    Mind the amount of teams you have available as well

    View Slide

  39. „Team assignments
    are the irst draft
    of the
    architecture”
    Michael Nygard
    Author of „Release It“
    36

    View Slide

  40. 37
    Let’s say we have a total of 50 people to build teams? How do we
    distribute them?
    Credit Sales
    Funnel
    Document
    Check
    Internal Scoring
    Security
    Assessment
    External Scoring
    Credit Decision Contract
    Proposal
    Contract
    Creation
    Credit
    Application
    Applicant
    Document
    Rule
    Clusters
    Securities
    External
    Rating
    Decision
    Template
    Decision
    Hierarchy
    Decision
    Contract
    Proposal
    Contract

    View Slide

  41. 37
    Let’s say we have a total of 50 people to build teams? How do we
    distribute them?
    Credit Sales
    Funnel
    Document
    Check
    Internal Scoring
    Security
    Assessment
    External Scoring
    Credit Decision Contract
    Proposal
    Contract
    Creation
    Credit
    Application
    Applicant
    Document
    Rule
    Clusters
    Securities
    External
    Rating
    Decision
    Template
    Decision
    Hierarchy
    Decision
    Contract
    Proposal
    Contract
    or

    View Slide

  42. 37
    Let’s say we have a total of 50 people to build teams? How do we
    distribute them?
    Credit Sales
    Funnel
    Document
    Check
    Internal Scoring
    Security
    Assessment
    External Scoring
    Credit Decision Contract
    Proposal
    Contract
    Creation
    Credit
    Application
    Applicant
    Document
    Rule
    Clusters
    Securities
    External
    Rating
    Decision
    Template
    Decision
    Hierarchy
    Decision
    Contract
    Proposal
    Contract

    View Slide

  43. Heuristics
    for team
    distribution
    38
    Things to keep in mind
    5-9 people per team
    Mind cognitive load of a team
    „You design it, you build it, you run it“
    Mind communication bandwidth
    Take subdomains into account

    View Slide

  44. 39
    “An architect should be thinking:
    Which team interaction modes
    are appropriate for these two
    teams?
    What kind of communication do
    we need between these two
    parts of the system, between
    these two teams?“

    View Slide

  45. Team Interaction Modes
    Image taken from the Team Topologies book

    View Slide

  46. 41
    Coupling of bounded
    contexts
    Although bounded contexts aim for
    a high degree of decoupling there
    needs to be some kind of connection
    between:
    •The teams
    •The software
    •The business capabilities

    View Slide

  47. Context Maps aim to
    deliver a holistic overview
    with regards to coupling
    of bounded contexts
    42

    View Slide

  48. 43
    Interactions between Bounded Contexts and teams
    Call Flow
    How are calls and
    events lowing within a
    system / context
    landscape?
    Model Propagation
    How do models
    propagate between
    systems? Where are
    boundaries?
    In luence of Actions
    How do the actions of
    one team affect other
    teams? Who in luences
    whom?
    or or
    Team
    Communication /
    Politics
    How do teams
    communicate with
    each other? Where are
    politics being played?
    or or

    View Slide

  49. 44
    Where should context maps help?
    Governance
    A Context Map helps to identify governance issues
    between applications and teams.
    Transformation
    A Context Map is an excellent starting point for future
    transformations: it gives an in-depth insight into
    integration aspects and subdomain / context relations
    Bad Models
    By introducing a Context Map we get a clear view
    on where and how bad models propagate through
    application landscapes
    Politics
    By not just looking at technical integration aspects
    the Context Map also helps us in seeing how teams
    communicate and „play politics“.

    View Slide

  50. 45
    Dependencies between teams
    Team
    Dependencies
    Mutually Dependent
    • Two software artifacts or systems in two
    bounded contexts need to be delivered together
    to be successful and work.
    • There is often a close, reciprocal link between
    data and functions between the two systems.
    Free
    • Changes in one bounded context do not in luence
    success or failure in other bounded contexts.
    • There is, therefore, no organizational or technical
    link of any kind between the teams.
    Upstream /
    Downstream
    • An upstream context will in luence the downstream
    counterpart while the opposite might not be true.
    • This might apply to code but also on less technical
    factors such as schedule or responsiveness to
    external requests.

    View Slide

  51. 46
    A brief overview of some of the context map
    patterns
    Open-host
    Service

    Public API

    One provider, several consumers

    General purpose

    Always upstream
    Anticorruption
    Layer
    Translation Iayer
    Model-to-Model transformation
    Reduces the amount of coupling
    Always downstream




    Published
    Language

    Shared „ubiquitous“ language

    Often de ined by a consortium

    Can be combined with Open-host service

    Examples: iCalendar, vCard, Zugferd
    Conformist
    One team adheres to an external model
    No translation of external models
    Motivation: simplicity or force
    Always downstream




    Shared Kernel

    Shared artifact

    Can be shared code, shared databases or
    shared libraries
    Customer /
    Supplier
    The downstream team can make demands
    The upstream has to ful ill them
    Negotiate and budget tasks
    Upstream / downstream




    View Slide

  52. 47
    System ABC
    System Y
    You can visualize
    different perspectives
    • Call Relationship

    View Slide

  53. 47
    System ABC
    Upstream
    Downstream
    System Y
    You can visualize
    different perspectives
    • Call Relationship
    • Team Relationship - Level 1

    View Slide

  54. 47
    System ABC
    Upstream
    Downstream
    System Y
    Open Host Service
    You can visualize
    different perspectives
    • Call Relationship
    • Team Relationship - Level 1
    • API Level

    View Slide

  55. 47
    System ABC
    Upstream
    Downstream
    System Y
    Open Host Service
    Anticorruption Layer
    You can visualize
    different perspectives
    • Call Relationship
    • Team Relationship - Level 1
    • API Level
    • Model Propagation

    View Slide

  56. 47
    System ABC
    Upstream
    Downstream
    System Y
    Open Host Service
    Anticorruption Layer
    You can visualize
    different perspectives
    Customer
    Supplier
    • Call Relationship
    • Team Relationship - Level 1
    • API Level
    • Model Propagation
    • Team Relationship - Level 2

    View Slide

  57. 48
    Context Map
    The context map is a powerful tool
    for
    •making implicitly hidden
    organizational processes visible
    •identify the low of bad domain
    models
    •establishing a decentralized
    governance model

    View Slide

  58. Alignment
    through
    Strategic
    DDD
    Orgainzation
    Team Topologies
    Context Maps
    Problem
    Space
    Problem Domain
    Subdomains
    Solution
    Space
    Bounded Context

    View Slide

  59. 50
    Domain-driven Design
    is an holisitic approach towards Software
    Architecture which goes beyond technical
    aspects by addressing cultural and
    organizational aspects of a delivery
    organization as well.

    View Slide

  60. Get my DDD book
    cheaper
    Book Voucher: 7.99 instead of (min) 9.99
    http://leanpub.com/ddd-by-example/c/speakerdeck

    View Slide

  61. Krischerstr. 100
    40789 Monheim am Rhein
    Germany
    +49 2173 3366-0
    Ohlauer Str. 43
    10999 Berlin
    Germany
    +49 2173 3366-0
    Ludwigstr. 180E
    63067 Offenbach
    Germany
    +49 2173 3366-0
    Kreuzstr. 16
    80331 München
    Germany
    +49 2173 3366-0
    Hermannstrasse 13
    20095 Hamburg
    Germany
    +49 2173 3366-0
    Gewerbestr. 11
    CH-6330 Cham
    Switzerland
    +41 41 743 0116
    innoQ Deutschland GmbH innoQ Schweiz GmbH
    www.innoq.com
    52
    Thank you!
    Michael Plöd
    Follow me on Twitter: @bitboss

    View Slide