Domain Driven Design (DDD)
Domain-Driven Design (DDD) is an approach to software development that centers the development process around a deep understanding of the domain (the specific area of business or problem being addressed). Instead of starting with technical details, DDD prioritizes collaborating closely with domain experts (people who deeply understand the business) to create a precise model of the domain. This model is then used to guide the design and implementation of the software.
- Ubiquitous Language: A common, consistent vocabulary shared by developers and domain experts to avoid misunderstandings and ensure everyone is on the same page. This language is directly reflected in the code.
- Domain Model: A conceptual model of the domain, often represented using diagrams and classes, that captures the key concepts, relationships, and rules within the business domain.
- Bounded Contexts: Dividing the domain into smaller, more manageable parts, each with its own ubiquitous language and domain model. This helps manage complexity.
The goal of DDD is to create software that is closer to the real-world business problems it solves, leading to more robust, maintainable, and adaptable systems. It’s particularly beneficial for complex domains where a deep understanding of the business rules is crucial.
Why domain driven design
-
Improved Communication and Understanding: DDD fosters collaboration between developers and domain experts, leading to a shared understanding of the business problem. The ubiquitous language minimizes misunderstandings and ensures everyone is speaking the same language.
-
More Accurate Software: By focusing on the domain model, DDD ensures the software accurately reflects the business rules and processes. This leads to a more reliable and useful system.
-
Increased Maintainability: A well-defined domain model makes the code easier to understand and maintain. Changes to the business requirements can be more easily incorporated into the software.
-
Better Adaptability: DDD promotes modularity through bounded contexts, allowing for more flexible and adaptable software. Changes in one part of the system are less likely to affect other parts.
-
Reduced Development Time (Long Term): While the initial investment in understanding the domain can seem time-consuming, the long-term benefits of reduced bugs, improved maintainability, and faster adaptation often lead to faster overall development time compared to less structured approaches.
-
Stronger Business Alignment: DDD ensures the software closely aligns with the business needs, resulting in a product that better meets the business goals.
In short, DDD is beneficial because it prioritizes a deep understanding of the business domain, resulting in software that is more accurate, maintainable, adaptable, and ultimately, more valuable to the business. It’s especially powerful when dealing with complex domains where a superficial understanding can lead to costly mistakes and significant rework.
Bounded Context vs Subdomain in DDD
In Domain-Driven Design (DDD), both Bounded Contexts and Subdomains are used to manage complexity within a large domain, but they represent different levels of abstraction:
- Subdomain: A Subdomain represents a specific area of responsibility within the overall business domain. Think of it as a major functional area. It’s a high-level conceptual division. For example, in an e-commerce system, subdomains might include “Order Management,” “Inventory Management,” “Customer Management,” and “Marketing.” Subdomains are often further broken down.
- Bounded Context: A Bounded Context defines the boundaries within which a particular model (Ubiquitous Language and associated domain objects) is valid. It’s a more concrete, implementation-focused concept. A single subdomain might encompass multiple bounded contexts. For example, the “Order Management” subdomain might have separate bounded contexts for “Order Placement,” “Order Fulfillment,” and “Order Cancellation.” Each of these contexts would have its own specific model and might even use different parts of the overall data model.
TL;DR
| Feature | Subdomain | Bounded Context |
|---|---|---|
| Abstraction Level | High-level, strategic | Low-level, tactical |
| Focus | Business capability | Model implementation and consistency |
| Scope | Broader, encompassing multiple contexts | Narrower, specific model and data |
| Relationship | A subdomain can contain multiple contexts | A context is part of a subdomain |
Analogy
NOTE
Imagine a large city (the overall domain). Subdomains are like the different boroughs or districts (e.g., finance, education, transportation). Bounded Contexts are like individual buildings or complexes within those districts (e.g., a specific bank branch within the finance district, a particular school within the education district). Each building has its own internal structure and rules, but they all contribute to the functioning of the larger district and the city as a whole.
Architectures Design Patterns for Scale
Monoliths
- A single unified application that contains : - UI - Business Logic - Data Access Logic
- All in one Codebase, deployed as one unit
✅ PROS :
- Simple to Build, Deployed at once
- Easy local dev and testing
- Less infrastructure overhead
❌ CONS :
- Harder to scale parts independently
When to Use What?
USE MONOLITH IF :
- You’re building a prototype or MVP
- You have a small dev team
- Requirements are still evolving rapidly
USE MICROSERVICES IF :
- If you are facing scalable bottlenecks
- have devops team
- have finalized MVP
A Balanced Path : Modular Monolith
- Write your code in modules/packages, even if its in one deployable
- Think “Single codebase, clean boundaries”
- This allow easy migration to microservices later
Service Boundaries and Communication
Define Clear service boundaries is essential to :
- Avoid tight coupling
- Enable modular design (monoliths/microservices)
- Minimize cross-team conflicts and dependency hell