Domain Driven Design Resurgence - Why now?
Domain Driven Design is about effective decomposition
Sudarshan leads the platform engineering capability within Deloitte Cloud & Engineering. He enjoys leading high-talent-density teams that architect, build and operate platforms that have an outsized impact on organisational performance indicators. He combines product management, architecture and engineering skills to build consensus across business units and organisational levels by showcasing a strong correlation between technology decisions and business drivers. Writings and opinions my own.
Key takeaways
Domain Driven Design (DDD) is a set of modelling techniques to enable effective decomposition.
We must break down big problems into smaller sub-problems, and the dimensions along which they are decomposed have an outsized impact on the outcomes. DDD provides proven techniques to reason about this decomposition at the strategic and tactical levels.
The slowing of Moore’s law and uptick in digital adoption is fuelling cloud adoption across the enterprise. The cloud favours distributed architectures, forcing enterprises to re-look at how they decompose their technology landscapes.
As businesses strive to optimise for both innovation and efficiency, they are taking a closer look at differentiating vs utility capabilities. They are challenging technology to be nimble and innovate for differentiating capabilities while staying cost-effective for their utility capabilities. These often opposing requirements from the business require technology to revisit how they recompose their monolithic, homogenous landscapes into business capability-aligned services.
Most organisations generate limited value from their transformation efforts because they locally optimise along the multiple interacting dimensions of business strategy, product, org design and tech strategy. DDD and Cynefin help deconstruct the complex interactions between these dimensions and provide a decision-making framework for optimising the whole, enabling organisations to make more targeted investment decisions.
Why Domain-Driven Design?
The slowing down of Moore's law, along with the uptick in digital adoption, has fuelled cloud adoption across sectors, cloud best supports distributed architectures, and this raises the question of how organisations should be decomposing their technology landscapes.
As businesses have grown in complexity, there is consensus that not all parts of a business have the same impact on organisational metrics, and execs want to double down on the differentiating capabilities within their business.
This recognition has fueled the need for heterogeneous technology architectures composed of:
Agile software solutions to power differentiating capabilities,
While leveraging commodity software to service utility domains.
In summary, there are now technology and business drivers for decomposition. DDD is a set of time-tested techniques (20+ years now) to enable business and technology alignment through effective decomposition.
Pre-DDD thinking
Here technology is the primary dimension of decomposition and little to no attention is given to aligning technology architectures with business domains to optimise organisational performance.
The Gartner PACE layered approach is a popular example of this outdated mental model.
We must revisit the idea that technology layers are self-contained as most business changes cut across layers. For example, adding new product categories to a website is not just about having an easy-to-change Content Management System; you must also update the database, integration points, warehouse systems, etc.
It is far more helpful to think about some business capabilities needing to be more responsive than others. For example, the digital touchpoints for a neobank (internet-only bank) need to be far more nimble than their internal payroll system.
The digital touchpoints are a differentiating capability, and the internal payroll system is a utility capability.
Strategic DDD thinking
Identify and categorise business capabilities
The DDD strategic patterns start by identifying differentiating capabilities vs utility capabilities.
Strictly speaking, DDD takes a more rigorous approach, referring to business capabilities as subdomains, where a subdomain is a fine-grained area of business activity and categorising them into Core (Differentiating), Supporting (supports a differentiating subdomain) and Generic (utility).
| Category | Description | Example |
| Core | A core subdomain is what a company does differently from its competitors. An organisation can succeed (or even exist) only by being exceptionally good in its core domain. | For a hypothetical ride-sharing company, the rider-to-driver match-making subdomain could be one of its core domains. |
| Supporting | Supporting subdomains support the company’s business. However, contrary to the core subdomains, supporting subdomains do not provide any competitive advantage for the company. They simply support the company’s core business. | For our hypothetical ride-sharing company, driver management could be a supporting subdomain. |
| Generic | Generic subdomains may require deep techno-functional skills but do not provide any competitive advantage. There is no need for innovation or optimisation here: battle-tested implementations are widely available. | And finally, the payments capability could be one of the generic subdomains. |
This visualisation helps brings these concepts together. The core subdomain is the area that provides a competitive advantage and requires deep techno-functional expertise. This organisational expertise is difficult to replicate and a crucial factor that sets the business apart from competitors.
subdomains and business capabilities are not synonymous, but for the purposes of this article the distinction is immaterial and so they are used interchangeably.
Leverage Cynefin framework to aid decision making
Identifying the core subdomain(s) is a dark science. Intuition and experience will inform some of these decisions, but leveraging complexity science, particularly the Cynefin framework, can help get better results by:
Deepening the thinking behind these decisions.
Providing consistent language to communicate the rationale across a diverse stakeholder group.
Identifying appropriate management strategies for each subdomain.
The Cynefin framework groups problems into four categories
When these are overlayed on the subdomain categories they enable us to validate our categorisation and provide tested techniques for addressing the unique needs of each subdomain category
| Cynefin Category | Description | Examples | Subdomain Category | Appropriate Responses |
| Complex | The domain of emergent practices and creative thinking | SpaceX recognised that it was dealing with a complex problem (as opposed to complicated) and optimised for discovery by running various safe-to-fail experiments to accelerate breakthrough knowledge acquisition. | Core | Optimise to minimise opportunity cost. Optimise for Experimentation and knowledge acquisition. Adopt iterative and incremental (agile) software development methodologies. Adopt a Product mindset. |
| Complicated | The domain of good practices and expert thinking | Large engineering projects like constructing dams, bridges, and buildings can be classified as complicated. These projects require specialised knowledge and expertise. While there are always multiple good practices to choose from, and one expert might do things differently than another, both would achieve the goals in the end. Fundamentally, the outcomes are still predictable. | Supporting and Generic | Optimise for cost and efficiency. Assemble a panel of experts and apply rigorous analysis techniques. Adopt linear and sequential (waterfall) software development methodologies. Adopt a Project mindset. |
| Clear | The domain of best practices and entrained thinking | Heavily process-oriented domains like support centres can be classified as clear. Call centre executives can resort to clear & well-defined processes to handle problems. There is unanimous agreement about the best course of action, and the response tends to be a process. Adhering to best practices and standard operating procedures delivers effective outcomes. | Generic | Optimise for cost and efficiency. Develop automation and standard operating processes. Adopt standard operating procedures supported by technology. |
| The domain of rapid response and action bias | The early days of the COVID-19 pandemic and the incubation phases of many start-ups can be classified as chaotic. People are most receptive to novelty and directive leadership in this context, and many innovations have emerged from chaotic situations. | N/A. Early stages of innovation, discovering product/market fit. Not yet an established subdomain. | Leverage design thinking and lean start-up techniques to validate product/market fit. |
Applying DDD and Cynefin to connect business and technology strategies
The primary dimension of decomposition is business capabilities, and the secondary dimension of decomposition could be technology.
Business Strategy
Business strategy involves identifying the core, supporting and generic business capabilities and developing necessary organisational conditions to maximise competitive advantage in the core subdomain, e.g. crafting new growth strategies while driving efficiencies in the supporting and generic subdomains, e.g. cost optimisation through vendor consolidation.
Capability strategy
Once subdomains have been categorised, we apply the Cynefin framework to derive the most appropriate management responses for each capability.
| Business Capability/ Subdomain Category | Success Indicators | Management response |
| Core | Delivers sustained competitive advantage. Minimises opportunity cost. The cost of pursuing opportunity is correlated with opportunity cost | Cynefin category - Complex Encourage knowledge discovery through fail-to-safe experiments, and challenge industry best practices. |
| Supporting | Delivers the required supporting capabilities for the core subdomain. Stable to lowering total cost of ownership balanced with agility needs of the core subdomain | Cynefin category - Complicated Favour battle-tested solutions and strongly consider adopting industry best practices. |
| Generic | Stable to lowering total cost of ownership while delivering required operational capabilities. | Cynefin category - Complicated or Clear Adopt battle-tested solutions, adopt industry best practices. |
Talent sourcing and team mindset
In this section, we’ll address the most appropriate talent-sourcing strategies and team mindsets for each subdomain category.
| Business Capability/ Subdomain Category | Talent sourcing model | Team structure |
| Core | Favour insourcing over partnering and outsourcing. Where organisations don’t have the appropriate skills, structure blended teams with a trusted partner and create incentives to develop the necessary skillsets. | Stable outcome-oriented, cross-functional (combined business and technology skills). |
| Supporting | Favour blended teams over outsourcing. Create blended teams with in-house leadership, leverage contract and/or partner talent for staff augmentation. | Scalable, task-oriented project teams. A skeleton team performs operations and steady-state activities. |
| Generic | Favour outsourcing. Minimal involvement of in-house technology talent | Outsourced project teams with little to no in-house technology team involvement. |
Technology
In this section, we’ll address facets across technology for each subdomain category.
| Business Capability/ Subdomain Category | Success Indicators | Buy vs Build | Key Architectural characteristics | Key Engineering practices |
| Core | Optimised for speed and stability to cater for high volatility and business criticality. | Build. | Speed is a competitive differentiator in this subdomain; hence evolvability over time (not just at a point in time) is a critical architectural characteristic. | Optimising for speed and stability calls for the most advanced engineering practices, e.g. Chaos engineering, CI/CD, A/B testing, and GitOps. |
| Supporting | Optimised for stability with just enough speed to cater for high business criticality and medium to low volatility. | Build or buy and customise. | Typically supporting subdomains have lower responsiveness demands than core subdomains; hence they value reliability and just enough evolvability while balancing the total cost of ownership. | Optimising for stability calls for good engineering practices, e.g. CI/CD, IaC. |
| Generic | Optimised for just enough stability to cater for medium business criticality and low volatility. | Buy. | While generic subdomains can be complicated, they have low volatility and business differentiation; hence they value reliability and low total cost of ownership over evolvability. | It's ideal to outsource this solution fully, but if that's not possible, it's important to practice basic engineering techniques such as Continuous Integration. |
Conclusion
Domain Driven Design combined with Cynefin framework enables organisations to make informed decisions across business strategy, organisational design and technology strategy using a set of proven techniques.
| Business Capability/ Subdomain Category | Description | Cynefin Category | Capability Success indicators | Appropriate solution response | Talent sourcing model | Team mindset | Technology success indicators | Buy vs Build | Key Architectural characteristics | Key Engineering practices |
| Core | A core subdomain is what a company does differently from its competitors. | Complex | Delivers sustained competitive advantage and minimises opportunity cost | Encourage knowledge discovery, through fail-to-safe experiments, challenge industry best practices | Favour insourcing over partnering and outsourcing. | Adopt a product mindset. | Optimised for speed and stability | Build. | Optimise for Evolvability and Reliability trading-off cost. | Most advanced engineering practices e.g. Chaos engineering, CI/CD, A/B testing, GitOps |
| Supporting | Supporting subdomains support the company’s business. However, contrary to the core subdomains, supporting subdomains do not provide any competitive advantage for the company. | Complicated | Delivers the required supporting capabilities for the core subdomain | Favour battle-tested solutions, and strongly consider adopting industry best practices. | Favour blended teams over outsourcing. | Adopt a blended team project mindset. | Optimised for stability | Build or buy and customise. | Optimise for reliability and just enough evolvability while balancing the total cost of ownership. | Good engineering practices e. g. CI/CD, IaC |
| Generic | Generic subdomains may require deep techno-functional skills but do not provide any competitive advantage. | Complicated OR Clear | Delivers required operational capabilities. | Adopt battle-tested solutions, adopt industry best practices | Favour outsourcing | Adopt an outsourced team project mindset. | Optimised for just enough stability | Buy | Optimise for reliability and low total cost of ownership trading-off evolvability. | Basic engineering practices (if any) like Continuous integration should be practised |
References
HBR Article on Decision Making
