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

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