---
title: "DDD"
description: "DDD (Domain-Driven Design) to podejście do projektowania oprogramowania wokół domeny biznesowej. Poznaj wspólny język, bounded contexty i agregaty."
url: "https://nodea.pl/pl/slownik-pojec/ddd"
lang: "pl"
updated: "2026-07-13"
---

# DDD

> DDD (Domain-Driven Design) to podejście do projektowania oprogramowania, w którym model kodu odzwierciedla domenę biznesową, a zespół posługuje się wspólnym językiem z ekspertami dziedzinowymi.

**DDD** (ang. *Domain-Driven Design*, projektowanie sterowane domeną) to podejście do tworzenia oprogramowania, w którym struktura i język kodu odzwierciedlają domenę biznesową — czyli obszar problemów, jakie system rozwiązuje. Sformułowane przez Erica Evansa w 2003 roku, zakłada ścisłą współpracę programistów z ekspertami dziedzinowymi oraz budowę modelu, który obie strony rozumieją tak samo.

## Na czym polega Domain-Driven Design?

DDD dzieli się na dwie warstwy. **Projektowanie strategiczne** porządkuje duży system: *wspólny język* (ubiquitous language) wymusza te same pojęcia w rozmowach, dokumentacji i kodzie; *bounded context* wyznacza granice, w których dany model obowiązuje (inaczej „klient” rozumie moduł sprzedaży, inaczej windykacji); *mapy kontekstów* opisują relacje między nimi. **Projektowanie taktyczne** dostarcza klocków wewnątrz kontekstu: encje (obiekty z tożsamością), obiekty wartości (niezmienne, porównywane po atrybutach), agregaty (spójne grupy obiektów ze wspólnym korzeniem i regułami), repozytoria, usługi domenowe oraz zdarzenia domenowe rejestrujące fakty biznesowe. Logika biznesowa mieszka w modelu domenowym, a nie w kontrolerach czy warstwie bazy danych — [framework](https://nodea.pl/pl/slownik-pojec/framework) jest szczegółem infrastruktury, wymienialnym bez naruszania reguł biznesowych.

## Zastosowanie w praktyce

DDD sprawdza się w systemach o złożonej, zmiennej logice: bankowości, ubezpieczeniach, logistyce, rozliczeniach czy dużych platformach e-commerce. Praktyczne korzyści:

- granice bounded contextów wprost wyznaczają podział na moduły lub mikroserwisy i zakresy odpowiedzialności zespołów;
- wspólny język skraca dystans między biznesem a kodem — wymagania tłumaczą się na model niemal 1:1;
- agregaty i zdarzenia domenowe ułatwiają utrzymanie spójności danych i audytowalność;
- czysty model domenowy dobrze współgra z [TDD](https://nodea.pl/pl/slownik-pojec/tdd), bo reguły biznesowe testuje się bez infrastruktury.

Warto jednak dobierać skalę środków do problemu: w prostych aplikacjach CRUD pełne DDD bywa przerostem formy nad treścią, a największą wartość dają wtedy same praktyki strategiczne — wspólny język i świadome granice kontekstów.

### Czy DDD ma sens w każdym projekcie?

Nie — pełne DDD opłaca się przy złożonej logice biznesowej, która stanowi o przewadze produktu. W prostych aplikacjach CRUD narzut modelowania przewyższa korzyści; wtedy warto stosować co najwyżej strategiczne elementy, jak wspólny język i podział na konteksty.

### Czym różni się DDD od architektury mikroserwisów?

DDD to metoda modelowania domeny, a mikroserwisy to styl wdrażania systemu — pojęcia niezależne, ale dobrze się uzupełniające. Bounded contexty z DDD są naturalnymi kandydatami na granice usług, dlatego DDD często poprzedza sensowny podział na mikroserwisy.

## Powiązane

- [Framework](https://nodea.pl/pl/slownik-pojec/framework)
- [TDD](https://nodea.pl/pl/slownik-pojec/tdd)
- [Refaktoryzacja](https://nodea.pl/pl/slownik-pojec/refaktoryzacja)
- [API](https://nodea.pl/pl/slownik-pojec/api)
- [Agile](https://nodea.pl/pl/slownik-pojec/agile)

---

Wersje językowe: [en](https://nodea.io/en/glossary/domain-driven-design.md)  
Spis treści witryny: [llms.txt](https://nodea.pl/pl/llms.txt)