Domain-Driven Design
Definition
Software development approach that focuses on modeling software to match business domains, enhancing collaboration and aligning technical solutions.
Use Cases
- Netflix: Evolving a large streaming platform with many independent teams and rapidly changing business capabilities (e.g., playback, personalization, content lifecycle). — Organized systems around microservices owned by teams, aligning service boundaries to business capabilities and using APIs/events to integrate. This approach is commonly associated with DDD concepts like bounded contexts and ubiquitous language, even when not labeled strictly as 'DDD' in every case. (Improved team autonomy and deployment independence, enabling faster iteration and scaling of different parts of the platform.)
- Amazon: Building and scaling a large e-commerce platform with distinct business areas such as ordering, payments, fulfillment, and catalog management. — Structured software around independently owned services aligned to business functions (often described as 'two-pizza teams' and service-oriented architecture). This maps well to DDD ideas: clear domain boundaries, explicit ownership, and integration via well-defined interfaces. (Enabled parallel development across many teams and supported large-scale growth by reducing tight coupling between business areas.)
- Uber: Managing complex, rapidly evolving domains such as trips, pricing, dispatch, and payments across a global ride-hailing platform. — Adopted a microservice architecture with domain-aligned services and clear ownership boundaries, using asynchronous messaging/events where appropriate. This aligns with DDD practices for separating domains and limiting cross-domain coupling. (Supported scaling engineering teams and systems while allowing different domains to evolve at different speeds.)
Frequently Asked Questions
- What's the difference between Domain-Driven Design and microservices?
- Domain-Driven Design (DDD) is a way to model and design software around the business domain (rules, processes, and language). Microservices are an architectural style for deploying software as small, independently deployable services. DDD can help you decide where microservice boundaries should be (bounded contexts), but you can use DDD without microservices, and you can build microservices without using DDD.
- When should I use Domain-Driven Design?
- Use DDD when the business problem is complex and the rules change often (for example, finance, insurance, logistics, healthcare, or large marketplaces). It’s especially helpful when multiple teams need a shared understanding of the business and when you want clear boundaries between parts of the system. For small apps with simple CRUD requirements and stable rules, DDD may add unnecessary overhead.
- How much does Domain-Driven Design cost?
- DDD has no direct licensing cost—it’s a set of practices. The main costs are time and staffing: workshops with domain experts, extra design effort, and potentially more engineering work to enforce boundaries (e.g., separate services, databases, or integration patterns). Cloud costs depend on how you implement it (number of services, databases, message queues, observability, and CI/CD), not on DDD itself.
Category: software
Difficulty: advanced
Related Terms
See Also