Domain-Driven Design (DDD)

Mis see on?
Domain-Driven Design (DDD) on tarkvaraarenduse lähenemine, mis keskendub keerukate süsteemide loomisele, sidudes koodi tugevalt reaalse äriloogikaga. Eesmärk on, et tarkvara struktuur ja keel vastaksid täpselt päriselu äriprotsessidele.

Mis etapid seal on?

DDD ei ole lineaarne protsess, vaid jaguneb kaheks disainitasandiks:

1. Strateegiline disain (Strategic Design)

Suure pildi haldamine ja süsteemi osadeks jagamine:

Ubiquitous Language (Ühtne keel): Ühine sõnavara, mida kasutavad nii arendajad kui ka ärieksperdid, et vältida tõlkimisvigu.
Bounded Contexts (Piiritletud kontekstid): Süsteemi jagamine selgeteks mooduliteks, kus igal terminil on kindel tähendus.

2. Taktikaline disain (Tactical Design)

Koodi tasandi mustrid lahenduste elluviimiseks:

Entities & Value Objects: Kuidas modelleerida objekte (kas identiteedi või väärtuse põhjal).
Aggregates: Objektide grupeerimine tehingute terviklikkuse tagamiseks.
Repositories: Abstraktsioon andmebaasisuhtluseks.

Kas sellel on alamvariante?

DDD-d kombineeritakse sageli järgmiste arhitektuurimustritega:

CQRS (Command Query Responsibility Segregation): Kirjutamise ja lugemise operatsioonide eraldamine efektiivsuse tõstmiseks.
Event Sourcing: Oleku salvestamine sündmuste jadana (mitte ainult hetkeseisuna).
Hexagonal Architecture (Ports & Adapters): Äriloogika isoleerimine välisest maailmast (UI, andmebaasid).

Arendusmudel joonisena

DDD Sibularhitektuur (Onion Architecture)
Joonise selgitus: Kõige keskel on puhas äriloogika (Domain Model), mis ei sõltu ühestki andmebaasist ega tehnoloogiast. Sõltuvused liiguvad alati väljast sissepoole.

Tähtsaim omadus: Ühtne keel (Ubiquitous Language)

See on DDD kõige kriitilisem osa. Kui koodis kasutatavad terminid erinevad sellest, mida äriinimesed räägivad, tekivad vead.

Näide: Kui logistikajuht ütleb "Kaup on teele pandud", siis koodis peab olema meetod shipment.dispatch(), mitte lihtsalt andmebaasi välja muutmine update status = 3.

Head ja Vead

Omadus	Head (Plussid)	Vead (Miinused)
Äriline täpsus	Tarkvara käitub täpselt nii nagu äri vajab.	Nõuab arendajatelt süvenemist äridetailidesse (mitte ainult koodi).
Hooldatavus	Kood on modulaarne ja muudatused on ohutumad.	Algne arendus on aeglasem suurema hulga failide ja kihtide tõttu.
Kasutusala	Ideaalne pikaajaliste ja keeruliste projektide jaoks.	Liiga keeruline (over-engineering) lihtsate veebilehtede jaoks.
Loe Martin Fowleri DDD kokkuvõtet

Kasutatud allikad ja lisalugemist

Selle mudeli süvitsi õppimiseks soovitame järgmisi materjale:

Eric Evansi "Domain Language" (DDD kodu) Microsofti juhend: CQRS ja DDD Martin Fowleri artiklid DDD-st

Tehtud koostöös AI-ga 2026