Mi a Domain-Driven Design (DDD)?

Question

Accepted Answer

**Domain-Driven Design (DDD)** egy szoftvertervezési megközelítés, amely arra összpontosít, hogy a szoftvert szorosan illesztse az **üzleti domainhez** — hangsúlyozva az üzleti szakértőkkel való együttműködést, a közös nyelvezetet, valamint a jól definiált domain-modellek és határok kialakítását. Értékes az összetett üzleti domainekhez.

## DDD alapvető gondolatai

```text
DDD centers the design on the BUSINESS DOMAIN (the real-world problem):
  ✓ UBIQUITOUS LANGUAGE → a shared, precise vocabulary between developers and domain
    EXPERTS, used consistently in code AND conversation (reduces miscommunication)
  ✓ MODEL the domain → rich domain models reflecting real business concepts/rules (not
    just data structures) — the model captures the business logic
  ✓ collaborate with domain EXPERTS → deeply understand the domain to model it well
```

## Stratégiai DDD (határok)

```text
BOUNDED CONTEXT → divide a large domain into bounded contexts, each with its own model
  and language (a term can mean different things in different contexts) → manage complexity
  → avoids one huge confused model; defines clear boundaries
CONTEXT MAPPING → define relationships/integration between bounded contexts
→ strategic DDD manages large, complex domains by dividing them sensibly
```

## Taktikai DDD (építőelemek)

```text
ENTITIES → objects with identity (tracked over time); VALUE OBJECTS → defined by attributes
  (no identity); AGGREGATES → clusters of entities with a root (consistency boundary)
REPOSITORIES → access aggregates; DOMAIN SERVICES → domain logic not fitting an entity;
DOMAIN EVENTS → things that happened in the domain
→ tactical patterns to model the domain richly
```

## Miért számít

A Domain-Driven Design megértése értékes senior szintű tudás, mivel ez egy **fontos megközelítés az összetett üzleti domainekkel való foglalkozásra** a domain közeli modellezésén keresztül, ezért fontos az összetett domainekhez készült szoftver tervezéséhez.

A DDD a tervezést az **üzleti domainre** összpontosítja — a szoftvert a valós problémához szorosan illesztve — ami értékes az összetett domainekhez, ahol maga az üzleti logika a fő kihívás.

Az **alapvető gondolatok** megértése — az **ubiquitous language** (közös, pontos szókincs a fejlesztők és domain-szakértők között, amely konzisztensen használatos a kódban és beszélgetésben, csökkentve az összetett projekteket sújtó félreértéseket), a **domain gazdag modellezése** (a domain-modellek valós üzleti fogalmakat és szabályokat tükröznek, nem csupán adatstruktúrák, befoglalva az üzleti logikát), és az **üzleti szakértőkkel való együttműködés** (a domain mélyreható megértése a jó modellezéshez) — megjeleníti a DDD központi filozófiáját, amely a szoftvert az üzlettel összhangzásba hozza.

A **stratégiai DDD** megértése — a **bounded contexts** (egy nagy domain felosztása kontextusokra, mindegyiknek saját modellje és nyelve van, mivel egy kifejezés különbözőképpen értelmezhető különböző kontextusban, kezeli a komplexitást és elkerüli az egy nagy zavaros modellt) és context mapping — tükrözi, hogyan kezeli a DDD a nagy, összetett domaineket azok értelmes felosztásával (értékes koncepció, amely a microservice határokhoz is kapcsolódik).

A **taktikai DDD** megértése — entities (identitás), value objects (attribútumok által definiáltak), aggregates (konzisztencia határok gyökerrel), repositories, domain services és domain events — biztosítja az építőelemeket egy domain gazdag modellezéséhez.

A DDD befolyásos az összetett üzleti szoftverhez, mind stratégiai (határok) mind taktikai (modellezés) útmutatást nyújtva.

Mivel a DDD az összetett üzleti domainekkel való foglalkozásra befolyásos megközelítés (szoros domain-modellezés, ubiquitous language, bounded contexts és gazdag domain-modellek révén), értékes az összetett szoftverekhez, és mivel alapvető gondolatainak, stratégiai határainak és taktikai mintáinak megértése fontos a domain-komplexitású rendszerek tervezéséhez, a Domain-Driven Design megértése értékes senior szintű tudás — befolyásos megközelítés az összetett üzleti domainekhez, amely szoros domain-modellezésre és egyértelmű határokra (bounded contexts) helyez hangsúlyt, fontos olyan szoftver tervezéséhez, ahol az üzleti komplexitás a fő kihívás, és tükrözi a senior fejlesztőktől összetett domainekkel foglalkozva elvárt tervezési kifinomultságot.