What are some signs that domain-driven design might be a good choice for an organization?
Sort by:
As we start in any architectural discussions, "It depends"!
To decide whether DDD is a suitable choice or otherwise, my suggestion is to run a SWOT (Strength-Weakness-Opportunity-Threat) Analysis.
Few pointers below:
Strengths:
- There is a tendency to build modular and loosely coupled services
- Align the business workforce aligned to the domain (some amount of BPR may be required)
Weakness:
- “Chaos” if each of Domain teams choose their own IT framework (as this freedom is available)
- API calls between Domains could result in performance issues
Opportunity:
- If your organization is looking into transitioning from On-prem to Cloud, DDD could fast-track this transition
Threat:
- Depending on how you implement Microservices (which is interwoven with DDD), you could end up creating huge services (Macro) or tiny services (Nano).
In summary, DDD requires lot of discipline and a bit of "brutal courage" to move ahead.
Domain-driven design can be a good choice for many organizations. For major retailers, for example, delivering value to the customer is paramount. Domain-driven design can help achieve that even in complex organizations with significant overlaps and dependencies.
The key is to understand what constitutes a domain and its boundaries, which can be subjective and vary from one organization to another. Standard domains like customer, order, product, price, promotion, inventory, and payment are common, but each organization needs to determine what makes sense for their specific context and leadership structure.
Ideally, you would design the organization according to these domains, but that rarely happens in practice. If the organization is not fully aligned with domain-driven design, it can still work but may not be as effective. Even so, it often makes sense to pursue it — but alignment and commitment from leadership are crucial.
Domain-driven design (DDD), is a valuable approach to software development, especially for complex environments where decentralized control exists, or where there are many interconnected parts or components that interact in less predictable ways. Instances where DDD is well suited include situations with multiple stakeholders or highly matrixed organizations where improved communications and collaboration are needed. Perhaps the biggest benefit of DDD is close collaboration between domain experts (business or functional teams) and developers, enabling a shared understanding of the domain and alignment of organizational goals to be achieved. Another benefit is that DDD can address simplification of disparate or legacy systems that have a history of quick fixes that adding a layer of complexity that can be addressed with a better, more efficient process.