Suggest an editImprove this articleRefine the answer for “What is Domain-Driven Design (DDD)?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)**Domain-Driven Design (DDD)** is an approach to designing software systems in which everything is built around the business domain, meaning around the real meaning and logic of the business, not around technologies, frameworks, or databases. **Key point:** the code model must be a mirror of business thinking, not just storing data but thinking the way the business thinks.Shown above the full answer for quick recall.Answer (EN)Image**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: ```python 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: ```python 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**.For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.