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

21a532a137b506128914478ac521fc8b?s=128

Michael Plöd

May 04, 2020
Tweet

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
  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.
  3. Get my DDD book cheaper Book Voucher: 7.99 instead of

    (min) 9.99 http://leanpub.com/ddd-by-example/c/speakerdeck
  4. 4 Speaker Michael Plöd Fellow at INNOQ Twitter: @bitboss

  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
  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.
  7. How do we solve the Problem? What Problem do we

    want to solve?
  8. 8 In order to align the what and the how

    we need communication between the business and the IT
  9. Business Domain Experts Developers Architects ? Software Engineering Domain Know-How

  10. What could possibly go wrong?

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

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

    Desk How developers name things TransparencyFactory RollableStuffContainer EntertainmentProviderSingleton DecoratorImpl RestProvider WorkEnablementDevice
  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
  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
  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
  16. 15 The bigger the alignment between problem and solution space,

    the better However, you’ll never be perfect
  17. The domain should be the heart of a system

  18. The domain should be the heart of a system Collaborative

    Modelling Continuous Learning Focus on linguistic details Inclusive Environment
  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
  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
  21. <<from the Domain-driven Design community>> Event Storming <<from the Domain-driven

    Design community>> Domain Storytelling 19 Popular Collaborative Modelling Techniques <<from the Behavior-driven Development community>> Example Mapping <<from the Agile / SCRUM community>> User Story Mapping
  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
  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
  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“
  25. „Not all parts of a system will be well designed“

    Eric Evans Author (and inventor) of „Domain-Driven Design“ 23
  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
  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
  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
  29. 26 Centralized models lead to many dependencies

  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
  31. The bounded context is a linguistic boundary around the meaning

    of a (domain) model 28
  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
  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
  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
  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
  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
  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
  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
  39. „Team assignments are the irst draft of the architecture” Michael

    Nygard Author of „Release It“ 36
  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
  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
  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
  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
  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?“
  45. Team Interaction Modes Image taken from the Team Topologies book

  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
  47. Context Maps aim to deliver a holistic overview with regards

    to coupling of bounded contexts 42
  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
  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“.
  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.
  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 • • • •
  52. 47 System ABC System Y You can visualize different perspectives

    • Call Relationship
  53. 47 System ABC Upstream Downstream System Y You can visualize

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

    You can visualize different perspectives • Call Relationship • Team Relationship - Level 1 • API Level
  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
  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
  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
  58. Alignment through Strategic DDD Orgainzation Team Topologies Context Maps Problem

    Space Problem Domain Subdomains Solution Space Bounded Context
  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.
  60. Get my DDD book cheaper Book Voucher: 7.99 instead of

    (min) 9.99 http://leanpub.com/ddd-by-example/c/speakerdeck
  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