Co rozumím návrhu řízenému doménou
On 15 listopadu, 2021 by adminDDD 101
Čím větší projekt, tím těžší je jeho údržba. Způsob, jak si s tím pomoci, je rozdělit aplikaci na menší oblasti podle jejich obchodních pravidel, známých jako domény.
Zásadně je doména oblast znalostí, buď veřejná, jako jsou pravidla šachu, nebo soukromá, jako jsou obchodní pravidla neziskové organizace .
Složitá doména bude pravděpodobně používat znalosti z jiných domén. Například nezisková organizace, která vyučuje šachy online, bude vědět o šachách, o výuce prostřednictvím online platforem a, i když vám jako studentovi nic neúčtuje, o svých financích.
Každá subdoména vaší domény je v DDD známá jako ohraničený kontext, každá má svůj vlastní model světa vytvořený pomocí specializovaných jednotek kódu, známých jako stavební bloky. Zde se zaměřím na entity a hodnotové objekty, na oba lze odkazovat jako na objekty.
Entity jsou objekty, které mají být v rámci domény jedinečné. Toho je dosaženo použitím jedné nebo více propriet pro identifikaci dané entity. Například dva uživatelé používající v systému stejné jméno budou mít vždy různé e-maily, protože e-maily se nemohou opakovat – nejčastěji se entity rozlišují pomocí id a někdy kombinací propriet.
Value-objects naproti tomu nemají identitu, takže k rozlišení dvou instancí lze použít pouze jejich vlastnosti. Vezměme si například dva pěšce (šachový žeton), vypadají stejně, pokud pocházejí ze stejné herní sady a mají stejnou barvu, takže nezáleží na tom, jestli je prohodíte. V DDD jsou hodnotové objekty neměnné, takže je snazší s nimi uvažovat.
Celost dat
Ohraničený kontext nevystavuje všechny své objekty, aby byla zaručena integrita jeho dat. Místo toho vystavuje některé kořeny agregátu jako jakési veřejné rozhraní sebe sama.
Agregát není nic jiného než entita, která se skládá z jiných objektů. Přesněji řečeno, agregát je shluk přidružených objektů, se kterými při změně dat zacházíme jako s jednotkou.
V praxi budou agregáty nabývat tvaru datové struktury známé jako strom. A z tohoto důvodu mají všechny agregáty kořen.
Jediným členem agregátu, na který se mohou odkazovat ostatní objekty, je jeho kořen, a proto jej vystavujeme. Takto se to dělá proto, že to brání ostatním objektům upravovat data způsobem, který agregát nemůže ovlivnit.
Důležité je objasnit, že ohraničený kontext může používat mnoho agregátů, i když jejich kořen není přímo vystaven vnějšímu světu.
Práce s více ohraničenými kontexty
Ale věci mohou být složitější, že? Každý ohraničený kontext dostane trochu jiný model stejných objektů, které mají jiné vlastnosti a chování. Takže uživatel v herním kontextu může mít vlastnost pro zacházení se svým skóre, která je ve finančním kontextu irelevantní, a tudíž neexistuje.
A to není všechno. Je také možné, aby doménový koncept, reprezentovaný jako entita v ohraničeném kontextu, byl v jiném kontextu reprezentován jako objekt-hodnota, nebo aby byl prostě zcela vynechán.
Například zatímco kontext výuky vyžaduje, aby učitelé byli reprezentováni jako entity, aby je bylo možné přiřadit studentům podle jejich id, kontext financí dává přednost tomu, aby byl „učitel“ viděn jako hodnota vlastnosti pozice entity zaměstnanec.
Některé další stavební kameny DDD jsou služby, úložiště, továrny a události. Pokusím se je stručně popsat.
Služby jsou schopnosti domény, které se přirozeně nehodí k entitám ani k objektům-hodnotám. Pozor na to, že se jedná o doménové služby, nikoliv o aplikační nebo infrastrukturní služby.
Repozitáře jsou mosty k úložným jednotkám – zdravíme CRUD!
Faktory jsou metody pro vytváření doménových objektů, aby nikdy neměly neplatné hodnoty. Tato část mě přiměla začít přemýšlet o testech řízených produkty.
Události jsou objekty, které představují něco, co se stalo v doméně – starají se o ně její experti. Skvělá příležitost pro vytvoření událostmi řízené aplikace .
Ačkoli si nepamatuji, že by to Evans uváděl, ohraničené kontexty jsou pěknou příležitostí, jak rozdělit kód na mikroslužby, kde každá služba je samostatným kontextem. Prvním krokem by mohlo být „virtuální“ rozdělení, kdy každý kontext umístíte do jiného modulu v téže aplikaci, a pokud zjistíte, že jsou opravdu izolované, přesunete je do jiných.
Jazyk, který vládne všem
Jednou z prvních věcí, kterou se lidé při studiu DDD naučí, je, že jejich systém by měl být popsán všudypřítomným jazykem. To znamená, že bychom měli psát kód pomocí stejných sloves (pro metody nebo služby) a podstatných jmen (pro objekty), jaká používají doménoví experti, když s námi mluví.
Psaní kódu tímto způsobem má výhodu v tom, že uzavírá komunikační propast mezi vývojáři a experty, když spolu mluví, ale je to přílišné zjednodušení reálného života, takže já osobně ho používám jako vodítko, ale ne jako konečné řešení.
Schoval jsem si to na konec, protože pro mě to nejdůležitější o DDD se většinou nedočtete, protože je to v „komplexní“ části knihy.
Nedávno jsem se dozvěděl, že sám autor říkal, že pořadí, v jakém věci v knize prezentuje, není optimální, a to, co jsem tu popsal, je blíž tomu, co by bylo ideální 😍. Slyšela jsem to v jednom podcastu, který na něj odkazuje
.
Napsat komentář