What are some signs that domain-driven design might be a good choice for an organization?
Sort By:
Oldest
Associate Director13 days ago
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.
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.