Suggest an edit

Improve this article

Refine the answer for “What is model in the context of DDD?”. Your changes go to moderation before they’re published.

Approval required

Content

What you’re changing

Title (EN)

Short answer (EN)

Shown above the full answer for quick recall.

Answer (EN)

In the context of **Domain-Driven Design (DDD)**, the term **model** means a **simplified but accurate representation of the domain**, that is, an **abstraction of the real business world, expressed in code and in the team's language**.

It is not just a "data structure": it is a **living conceptual model** that describes **how the business works and what rules govern it**.

---

### 1. **The essence: what a model is**

> A model is a way to **understand, explain, and implement** the behavior of the domain in code.

It reflects:

- the business's terms,
- rules and constraints,
- relationships between objects,
- reactions to events.

The model is what turns the "chaos of requirements" into a **structured system of concepts** the developer works with.

---

### 2. **A model is not data, it is meaning**

Ordinary code stores data (`user_name`, `order_date`).
A model instead expresses *meaning*:

```python
order.pay(amount)
```

not just "record a payment," but "carry out the business action of paying," with all its rules (a cancelled order cannot be paid, an order cannot be partially paid, and so on).

---

### 3. **What a model consists of**

A DDD model is built from domain building blocks:

| Component | Role in the model |
|---|---|
| **Entity** | Represents an object with identity and a lifecycle (`Order`, `Customer`). |
| **Value Object** | Represents a characteristic without identity (`Money`, `Address`). |
| **Aggregate** | A group of related entities with consistency logic. |
| **Domain Service** | Behavior that does not belong to a single entity (`PaymentService`). |
| **Domain Event** | A fact that happened in the business (`OrderCancelled`). |

All of these elements **together make up the domain model**.

---

### 4. **A model is also a language**

DDD emphasizes that a model lives not only in code, but also in conversation.
Developers, analysts, and experts should use a **shared vocabulary (Ubiquitous Language)**.
Then the code becomes a direct reflection of the business's concepts.

---

### 5. **Example**

The business says:

> "If a product runs out, the order should move to a status of waiting for restock."

A DDD model does not express this as `if count == 0`,
but as:

```python
class Product:
    def reserve(self, quantity):
        if not self.in_stock(quantity):
            raise OutOfStock()
        self.stock -= quantity
```

Here **the model does not just store fields**, it **describes the behavior of the domain**.

---

### Conclusion:

- **Domain** is *the business world* (what actually happens).
- **Model** is *a clear and accurate reflection of that world in code and in the team's language*.

DDD begins where the code stops being "about data"
and becomes **about meaning, rules, and decisions**.

Markdown · drag & drop images · ⌘B / ⌘I shortcuts442 words

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.