Domain driven design vs Active Record

__
Člen | 2
+
0
-

Ahoj,
začal jsem se zajímat o DDD a moc se mi to líbí. Bohužel jsem nucen používat Nette DB, která funguje spíš na principech Active Record. Takže DDD pro mě nepřipadá v úvahu, správně? Nebo je možné designovat appku i s Nette Database, tak aby to bylo podle principů DDD?

Jak strukturujete svůj projekt s Nette\Database? Rád bych došel do stavu, kdy v presentery budou fakt tenké. Koncept DDD mi přijde čistý a pochopitelný, jak to ale dělat správně při použití Active Record mi není úplně jasné. Jak má vypadat model? Co zde jsou entity? Jsou zde nějaké repository (služby/whatever .. podobně jako v DDD?). Rád bych dosáhnul co „nejčistějšího“ kódu v rámci možností.

Díky

Svaťa Šimara
Člen | 98
+
0
-

Pokud chceš postupovat podle DDD, budeš mít čisté objekty nezávislé na infrastruktuře (v tomto případě Nette\Database).

Persistenci řeší repozitáře, ty jsou abstraktní. Konkrétní implementace – NetteDatabaseXXXRepository už bude na Tobě. V případě jednoduché entity to bude cajk – provedeš SQL, dostaneš ActiveRow a vytvoříš příslušný doménový objekt. V případě složitějších objektů obsahujících kolekce to už bude mazec. Stejně tak aktualizace…

Narazíš na velké množství problémů, které bych osobně raději neřešil. Takže nakonec to půjde, ale proč?

__
Člen | 2
+
0
-

Svaťa Šimara napsal(a):

Pokud chceš postupovat podle DDD, budeš mít čisté objekty nezávislé na infrastruktuře (v tomto případě Nette\Database).

Persistenci řeší repozitáře, ty jsou abstraktní. Konkrétní implementace – NetteDatabaseXXXRepository už bude na Tobě. V případě jednoduché entity to bude cajk – provedeš SQL, dostaneš ActiveRow a vytvoříš příslušný doménový objekt. V případě složitějších objektů obsahujících kolekce to už bude mazec. Stejně tak aktualizace…

Narazíš na velké množství problémů, které bych osobně raději neřešil. Takže nakonec to půjde, ale proč?

Nebylo mi jasné především jedno, jak do Entity (potomka ActiveRow) dostanu doménovou logiku. Vy jste mi v podstatě potvrdil co jsem si myslel, že z té ActiveRow entity budu muset někde udělat doménový objekt („doménovou entitu“, nebo prostě „entitu“). Moc mi nebylo jasné kde, ale hádám, že by to měla dělat implementace konkrétního mapperu uvnitř repository. Já netvrdím, že to takto chci dělat s NetteDb, to bych si víc práce přidělal. Došel jsem k tomu, že je to blbost už v době psaní původního dotazu. Tedy především to, že kdybych chtěl postupovat podle DDD, měl bych pak tu zodpovědnost za namapování přes NetteDb do db.. což nechci. Nedokážu si představit, kolik jak bych to řešil u nějakých složitějších agregátů.

Takže DDD + Nette DB = myslím že určitě ne. O to víc mě zajímá teď právě jak to dělat čistě v duchu Active Recordu :-) Vím, že právě základ AR je míchat data i doménovou logiku dohromady. Já bych chtěl však dosáhnout nějaké dekompozice do menších celků a izolovanosti …v rámci možností. Nejde mi o to, abych přidával vrstvy protože je to cool, chci jen psát hezčí a udržovatelnější kód. Díky

Editoval __ (22. 7. 2017 15:21)

newPOPE
Člen | 648
+
0
-

Akurat pracujem na projekte kde nove veci (niekedy aj stare ked treba nieco prerobit/zmenit) robim v duchu DDD. Odhliadnuc od toho, ze sa adresare, triedy… dost zacinaju rozsirovat a kosatit je to velmi vyhodne hlavne pri testovani, zmene funkcionality alebo repozitara (pred par dnami som proste reimplementovat DatabaseFooRepository na DoctrineFooRepository a slapalo to okamzite.
Cize doteraz som pisal repozitare tak aby mi to konvertovali na DOmenovy Objekt (entita, value objecty niekde som si sem tam injektol Database\Context kvoli kolekciam. Napr. Order → OrderItems).

Nasledne ma uz pisanie tych mapovani/ukladani/buildovani domenovych objektov zacalo vytacat tak som si tam pridal Doctrine (nie Kdyby\Doctrine ale len Doctrine). No a ked uz je tam DOctrine tak si treba vybrat mapping, nepouzivam annotation mapping lebo ten je sice fajn ale zasahujes z infrastruktury do domeny co vo vysledku nechces. Cize pouzivam yaml mapping. Vsetko to krasne funguje a vsetci su spokojni.

Co sa tyka vety od @SvaťaŠimara

Narazíš na velké množství problémů, které bych osobně raději neřešil. Takže nakonec to půjde, ale proč?

Tak ano ked si dane entity a vazby medzi nimi napises velmi zlozite a „dlhe“ ($user->orders->orderItems->first()->created) tak to bude pain riesit. Je to len na tebe ako si postavis dane entity, agregaty aby si taketo veci nemusel riesit a mal to jednoduche a prehladne.

Editoval newPOPE (23. 7. 2017 19:19)