What is Domain-Driven Design (DDD)?
Domain-Driven Design (DDD) is an approach to designing software systems in which everything is built around the business domain - that is, around the real meaning and logic of the business, not around technologies, frameworks, or databases.
The main idea of DDD:
Code should reflect business reality, not the structure of database tables or the quirks of a framework.
1. What "domain" means
A domain is the area of knowledge the system operates in. For example:
- for a bank: loans, accounts, transfers;
- for an online store: products, orders, the cart;
- for a CRM: customers, deals, communications.
DDD says:
first understand how this world works, and only then write code.
2. The key goal
Build a model that:
- reflects the real business rules,
- is understandable to both developers and domain experts,
- is isolated from infrastructure.
3. Core DDD concepts
| Concept | What it is |
|---|---|
| Ubiquitous Language | A shared vocabulary between developers and the business. One term, one meaning, in code and in speech. |
| Entity | An object with identity and a lifecycle. Example: User, Order. |
| Value Object | An object without identity, where only its properties matter. Example: Money (currency + amount). |
| Aggregate | A group of related entities and value objects united by logic. Example: an Order and its items. |
| Aggregate Root | The main entity through which the whole aggregate is managed. |
| Repository | An interface for retrieving and saving aggregates (database access is abstracted away). |
| Service (Domain Service) | An action that does not belong to a specific entity but matters to the domain. |
| Domain Event | An event that happened in the business logic and can trigger reactions in other parts of the system. |
4. DDD and architecture
DDD pairs well with Clean Architecture. Clean Architecture is about structure and dependencies, while DDD is about the meaning and language living inside those layers.
The domain (entities, aggregates, value objects, domain services) is usually placed at the center of Clean Architecture.
5. An intuitive example:
Instead of:
def create_order(user_id, items):
db.insert("orders", user_id, items)DDD forces you to ask:
- What does "creating an order" mean from a business perspective?
- Can an order be created without payment?
- What happens if a product is out of stock?
Then domain classes appear in the code:
class Order:
def add_item(self, product, quantity):
if not product.in_stock(quantity):
raise OutOfStockError()
self.items.append(OrderItem(product, quantity))Now the logic describes real business meaning, not a SQL record.
6. The main principle of DDD
The code model must be a mirror of business thinking. Not just storing data, but thinking the way the business thinks.
Short Answer
Interview readyA concise answer to help you respond confidently on this topic during an interview.