Knihu nepotrebujes by som povedal. Staci len pochopit koncept. DDD je proste o tom ze si musis rozkuskovat projekt na domeny kde kazda ma vlastne procesy a datove struktury do ktorych ina domena nemoze zasahovat a moze si takto zit vlastnym zivotom(napriklad ked nastane merger dvoch firiem tak su to samostatne domeny kde treba vymysleit ako budu so sebou komunikovat ale stale su to de facto izolovane kontexty). A nasledne tieto domeny potom poprepajas. Je to cisto iba o tom ze vrstvis urovne logiky na seba ako cibulu. Napriklad si vezmi nejaku velku korporaciu - mas tam uctovne oddelenie, mas tam nakupne oddelenie a mas tam predajne oddelenie. Kazde same o sebe je izolovany svet kde su iste pravidla, to je ta domena, a musis ich potom prepojit aby vedeli so sebou pracovat. To je ta vrstva nad. Napriklad v domene uctovnictvo je email klienta alebo odberatela iba jeden malo-vyznamny kontaktny udaj, ale napriklad v online marketingovom oddeleni je to unikatny identifikator uzivatela a pracuju tam s nim inak. Takze napriklad v uctovnom oddeleni by to bolo iba policko v db kdezto v marketingovom oddeleni by to bol primarny index v db. A td skratka. Je to iba izolacia kontextu, nic viac. Toto sa knihami nenaucis, to treba robit
Ja de fact orobim ddd uz par rokov lebo som s tym zacla pre jedne projekt a uz som si zvykol. Zaroven aj event sourcing a napriklad aktualne aj CQRS.
- -
Este zjednodusenejsie by som to popisal ako ze kazda domena je akoby kniznica ktora ma interface cez ktory moze komunikovat s vonkajsim svetom(v DDD sa to tusim vola ports/adapaters ale je to proste interface). A to je cele proste. Netreba pre to citat 300 strankove knihy.