Domain-Driven Design (DDD) je přístup k vývoji softwaru, který se zaměřuje na pochopení a modelování problémové domény, ve které softwarový systém funguje. Zdůrazňuje, že je důležité úzce spolupracovat s odborníky na doménu s cílem dosáhnout hlubokého porozumění složitosti a složitosti domény. DDD poskytuje sadu principů, vzorů a postupů, které pomáhají vývojářům efektivně zachytit a vyjádřit koncepty domén ve svých softwarových návrzích.

jak spustit skript

Důležitá témata pro návrh řízený doménou (DDD)

• Co je to doménou řízený design (DDD)?
• Význam znalosti domény
• Strategický design v designu řízeném doménou (DDD)
• Vzory taktického návrhu v návrhu řízeném doménou (DDD)
• Výhody návrhu řízeného doménou (DDD)
• Výzvy návrhu řízeného doménou (DDD)
• Use-Cases of Domain-Driven Design (DDD)
• Reálný příklad návrhu řízeného doménou (DDD)

Co je to doménou řízený design (DDD)?

Doména

Odkazuje na předmětnou oblast nebo problémový prostor, pro který je softwarový systém vytvářen. Zahrnuje koncepty, pravidla a procesy v reálném světě, které má software modelovat nebo podporovat. Například v bankovní aplikaci doména zahrnuje pojmy jako účty, transakce, zákazníci a předpisy související s bankovními operacemi.

Řizen

Driven znamená, že návrh softwarového systému je řízen nebo ovlivněn vlastnostmi a požadavky domény. Jinými slovy, rozhodnutí o návrhu jsou založena na hlubokém porozumění dané doméně, spíše než aby byla řízena pouze technickými úvahami nebo detaily implementace.

Design

Design odkazuje na proces vytváření plánu nebo plánu pro softwarový systém. To zahrnuje rozhodnutí o tom, jak bude systém strukturován, jak budou různé komponenty interagovat a jak bude systém plnit své funkční a nefunkční požadavky. V kontextu Domain-Driven Design se zaměřujeme na navrhování softwaru způsobem, který přesně odráží strukturu a chování domény.

Domain-Driven Design je koncept představený programátorem Eric Evans v roce 2004 ve své knize Návrh řízený doménou: Řešení složitosti v srdci softwaru

Význam znalosti domény

Předpokládejme, že jsme navrhli software s využitím všech nejnovějších technologií a infrastruktury a naše architektura návrhu softwaru je úžasná, ale když tento software uvedeme na trh, je to nakonec koncový uživatel, kdo rozhodne, zda je náš systém skvělý nebo ne. Také pokud systém neřeší obchodní potřeby, pak je pro nikoho k ničemu. Bez ohledu na to, jak pěkně vypadá nebo jak kvalitní je architektura jeho infrastruktury.

Podle Eric Evans , Když vyvíjíme software, naše zaměření by se nemělo primárně soustředit na technologii, ale mělo by být primárně na podnikání. Pamatovat si,

Úkolem zákazníka není vědět, co chce – Steve Jobs

Strategický design v designu řízeném doménou (DDD)

Strategický návrh v Domain-Driven Design (DDD) se zaměřuje na definování celkové architektury a struktury softwarového systému způsobem, který je v souladu s problémovou doménou. Zabývá se otázkami na vysoké úrovni, jako je organizace konceptů domén, rozdělení systému na spravovatelné části a stanovení jasných hranic mezi různými komponentami.

vytvoření věštecké tabulky

Podívejme se na některé klíčové koncepty v rámci strategického designu v doménovém designu (DDD)

1. Ohraničené kontexty

• Ohraničený kontext představuje specifickou oblast v rámci celkové problémové domény, kde důsledně platí konkrétní model nebo jazyk.
• Různé části systému mohou mít různé významy pro stejné termíny a Ohraničený kontext definuje explicitní hranice, ve kterých mají tyto termíny specifické významy.
• To umožňuje týmům vyvíjet modely, které jsou přizpůsobeny konkrétním kontextům, aniž by docházelo k nejasnostem nebo nesrovnalostem.
• Ohraničené kontexty pomáhají zvládat složitost tím, že rozdělují velkou, komplexní doménu na menší, lépe spravovatelné části.

2. Mapování kontextu

• Kontextové mapování je proces definování vztahů a interakcí mezi různými ohraničenými kontexty.
• Zahrnuje identifikaci oblastí překrývání nebo integrace mezi kontexty a vytváření komunikačních kanálů a dohod mezi nimi.
• Kontextové mapování pomáhá zajistit, aby různé části systému mohly efektivně spolupracovat a přitom mezi nimi byly zachovány jasné hranice.
• Existují různé vzory a techniky pro kontextové mapování, jako je partnerství, sdílené jádro a zákazník-dodavatel.

3. Strategické vzory

• Strategické vzory jsou obecné pokyny nebo principy pro organizaci architektury softwarového systému způsobem, který je v souladu s problémovou doménou.
• Tyto vzory pomáhají řešit běžné problémy při navrhování složitých systémů a poskytují osvědčené přístupy pro efektivní strukturování systému.
• Příklady strategických vzorů zahrnují Agregáty, Doménové události a Protikorupční vrstva.
• Tyto vzory poskytují řešení opakujících se problémů v návrhu řízeném doménou a pomáhají zajistit, aby architektura systému přesně odrážela základní koncepty domény.

4. Sdílené jádro

• Sdílené jádro je strategický vzor, ​​který zahrnuje identifikaci oblastí shodných mezi různými ohraničenými kontexty a vytvoření sdílené podmnožiny modelu domény, který se používá ve více kontextech.
• Tato sdílená podmnožina neboli jádro pomáhá usnadnit spolupráci a integraci mezi kontexty a zároveň umožňuje každému kontextu zachovat si svůj vlastní odlišný model.
• Sdílené jádro by mělo být používáno uvážlivě, protože zavádí závislosti mezi kontexty a může vést ke spojení, pokud není spravováno pečlivě.

5. Anti-Corruption Layer (ACL)

• Anti-korupční vrstva je dalším strategickým vzorem, který pomáhá chránit systém před vlivem externích nebo starších systémů, které používají různé modely nebo jazyky.
• ACL funguje jako překladová vrstva mezi externím systémem a modelem hlavní domény a podle potřeby transformuje data a zprávy, aby byla zajištěna kompatibilita.
• To umožňuje, aby model hlavní domény zůstal čistý a zaměřený na problémovou doménu, a přitom se podle potřeby stále integroval s externími systémy.

6. Všudypřítomný jazyk

Všudypřítomný jazyk označuje sdílenou slovní zásobu nebo jazyk, který se používá konzistentně a univerzálně mezi všemi zúčastněnými stranami zapojenými do vývoje softwarového systému. Tento jazyk se skládá z termínů, frází a konceptů, které přesně reprezentují znalosti a koncepty domény.

Některé z klíčových principů všudypřítomného jazyka jsou:

• Sdílené porozumění : Primárním cílem Ubiquitous Language je vytvořit sdílené chápání problémové domény mezi všemi členy vývojového týmu, včetně vývojářů, doménových expertů, obchodních analytiků a zainteresovaných stran. Použitím společného jazyka mohou všichni zúčastnění komunikovat efektivněji a přesněji předat doménové koncepty a požadavky.
• Důslednost a srozumitelnost : Všudypřítomný jazyk podporuje konzistenci a srozumitelnost v komunikaci pomocí přesné a jednoznačné terminologie. Každý termín nebo fráze v jazyce by měl mít jasný a dohodnutý význam,
• Zarovnání s obchodními koncepty : Jazyk používaný v DDD by měl být v souladu s terminologií a koncepty používanými v obchodní doméně. Měl by odrážet způsob, jakým doménoví experti přemýšlejí a mluví o problémové doméně, a zajišťuje, že software přesně reprezentuje koncepty a procesy reálného světa.
• Evoluční povaha : Všudypřítomný jazyk není statický, ale postupem času se vyvíjí, jak tým získává hlubší znalosti o doméně a jak se mění požadavky. Měl by se přizpůsobit tak, aby odrážel nové poznatky, objevy nebo změny v obchodních prioritách, a zajistit, aby jazyk zůstal relevantní a aktuální během procesu vývoje.

Vzory taktického návrhu v návrhu řízeném doménou (DDD)

V Domain-Driven Design (DDD) jsou taktické vzory návrhu specifické strategie nebo techniky používané ke strukturování a organizaci modelu domény v rámci softwarového systému. Tyto vzory pomáhají vývojářům efektivně zachytit složitost domény a zároveň podporovat udržovatelnost, flexibilitu a škálovatelnost.

Podívejme se na některé z klíčových taktických návrhových vzorů v DDD:

1. Entita

Entita je objekt domény, který má odlišnou identitu a životní cyklus. Entity jsou charakterizovány svými jedinečnými identifikátory a měnitelným stavem. Zapouzdřují chování a data související s konkrétním konceptem v doméně.

Například v bankovní aplikaci aBankAccount>entita může mít vlastnosti, jako je číslo účtu, zůstatek a vlastník, spolu se způsoby vkladu, výběru nebo převodu finančních prostředků.

2. Hodnotový objekt

Hodnotový objekt je doménový objekt, který představuje koncepčně neměnnou hodnotu. Na rozdíl od entit nemají hodnotové objekty odlišnou identitu a obvykle se používají k reprezentaci atributů nebo vlastností entit. Hodnotové objekty jsou rovnocenně srovnatelné spíše na základě jejich vlastností než identity.

Například aMoney>value object může představovat konkrétní částku měny, zapouzdřující vlastnosti, jako je typ měny a částka.

3. Agregát

• Agregát je shluk objektů domény, které jsou považovány za jednu jednotku pro účely konzistence dat a transakční integrity.
• Agregáty se skládají z jedné nebo více entit a hodnotových objektů, přičemž jedna entita je označena jako agregovaný kořen.
• Kořen agregátu slouží jako vstupní bod pro přístup a úpravu vnitřního stavu agregátu.
• Agregáty vynucují hranice konzistence v rámci modelu domény a zajišťují, že změny souvisejících objektů jsou prováděny atomicky.

Například v systému elektronického obchodování, anOrder>agregát se může skládat z entit jakoOrderItem>aCustomer>, sOrder>entita sloužící jako agregovaný kořen.

4. Úložiště

• Úložiště je mechanismus pro abstrahování přístupu k datům a logiky perzistence z modelu domény.
• Repozitáře poskytují standardizované rozhraní pro dotazování a ukládání doménových objektů a skrývají podrobnosti o tom, jak jsou data získávána nebo ukládána. Repozitáře zapouzdřují logiku pro překlad mezi doménovými objekty a základními mechanismy ukládání dat, jako jsou databáze nebo externí služby.
• Oddělením modelu domény od problémů s přístupem k datům umožňují úložiště větší flexibilitu a udržovatelnost.

Například aCustomerRepository>může poskytovat metody pro dotazování a ukládáníCustomer>entity.

5. Továrna

• Továrna je a stvořitelský vzor používá se k zapouzdření logiky pro vytváření instancí komplexních doménových objektů. Továrny abstrahují proces konkretizace objektů a umožňují klientům vytvářet objekty, aniž by potřebovali znát detaily jejich konstrukce.
• Továrny jsou zvláště užitečné pro vytváření objektů, které vyžadují složitou inicializační logiku nebo zahrnují více kroků.

Například aProductFactory>může být zodpovědný za vytváření instancíProduct>entity s výchozí konfigurací.

6. Servis

• Služba je doménový objekt, který představuje chování nebo operaci, která přirozeně nepatří žádné konkrétní entitě nebo hodnotovému objektu.
• Služby zapouzdřují doménovou logiku, která funguje na více objektech nebo organizuje interakce mezi objekty.
• Služby jsou obvykle bezstavové a zaměřují se na provádění konkrétních úkolů nebo vynucování pravidel domény.

Například anOrderService>může poskytovat metody pro zpracování objednávek, uplatnění slev a výpočet nákladů na dopravu.

Výhody návrhu řízeného doménou (DDD)

• Sdílené porozumění :
  • Podporuje spolupráci mezi doménovými experty, vývojáři a zúčastněnými stranami.
  • Díky podpoře sdíleného porozumění problémové doméně prostřednictvím všudypřítomného jazyka mohou týmy komunikovat efektivněji a zajistit, aby software přesně odrážel potřeby a požadavky podniku.
• Zaměřte se na hlavní doménu :
  • Pomáhá týmům identifikovat a upřednostňovat hlavní doménu aplikace – oblasti systému, které podniku poskytují největší hodnotu. Zaměřením vývoje na hlavní doménu mohou týmy poskytovat funkce, které přímo řeší obchodní cíle a odlišují software od konkurence.
• Odolnost vůči změně :
  • Klade důraz na navrhování softwarových systémů, které jsou odolné vůči změnám, modelováním domény způsobem, který odráží přirozené složitosti a nejistoty problémové domény.
  • Přijetím změn jako přirozené součásti vývoje softwaru mohou týmy efektivněji reagovat na vyvíjející se obchodní potřeby a tržní podmínky.
• Jasné oddělení obav :
  • DDD podporuje jasné oddělení zájmů mezi doménovou logikou, infrastrukturou a uživatelským rozhraním. Izolací doménové logiky od technických detailů a problémů s infrastrukturou mohou týmy udržovat čistý a zaměřený doménový model, který je nezávislý na konkrétních implementačních detailech nebo technologických volbách.
• Vylepšená testovatelnost :
  • Podporuje používání doménových objektů s dobře definovanými hranicemi a chováním, což usnadňuje psaní lepších a cílených testů, které ověřují správnost doménové logiky.
  • Při navrhování softwarových systémů s ohledem na testovatelnost mohou týmy zajistit, že změny v kódové základně jsou bezpečné a předvídatelné, čímž se sníží riziko zavedení regresí nebo nezamýšlených vedlejších účinků.
• Podpora pro komplexní obchodní pravidla :
  • Poskytuje vzory a techniky pro modelování a implementaci komplexních obchodních pravidel a pracovních postupů v rámci modelu domény.
  • Explicitním zastoupením obchodních pravidel v modelu domény mohou týmy zajistit, aby software přesně odrážel složitosti obchodní domény a prosazoval omezení a požadavky specifické pro doménu.
• Soulad s obchodními cíli :
  • V konečném důsledku si klade za cíl sladit úsilí o vývoj softwaru se strategickými cíli a záměry podnikání. Zaměřením se na pochopení a modelování problémové domény mohou týmy dodávat softwarová řešení, která přímo podporují obchodní cíle, podporují inovace a vytvářejí hodnotu pro zúčastněné strany a koncové uživatele.

Výzvy návrhu řízeného doménou (DDD)

• Složitost :
  • DDD může představovat složitost, zejména ve velkých a složitých doménách.
  • Přesné modelování složitých obchodních domén vyžaduje hluboké pochopení domény a může zahrnovat řešení nejednoznačnosti a nejistoty. Efektivní řízení této složitosti vyžaduje pečlivé plánování, spolupráci a odborné znalosti.
• Všudypřítomná adopce jazyka :
  • Vytvoření a udržování všudypřítomného jazyka – sdílené slovní zásoby, která přesně reprezentuje koncepty domény – může být náročné. Vyžaduje to spolupráci mezi vývojáři a odborníky na domény, aby bylo možné identifikovat a dohodnout se na termínech a významech domény.
  • Dosažení konsenzu o všudypřítomném jazyce může vyžadovat překonání komunikačních bariér a sladění rozdílů v terminologii a perspektivách.
• Zarovnání ohraničeného kontextu :
  • Ve velkých a komplexních doménách mohou mít různé části domény odlišné modely a ohraničené kontexty. Zarovnání těchto ohraničených kontextů a zajištění konzistence mezi nimi může být náročné.
  • Vyžaduje jasnou komunikaci, spolupráci a koordinaci mezi týmy pracujícími na různých částech domény, aby se předešlo nesrovnalostem a konfliktům.
• Technická složitost :
  • Efektivní implementace principů a vzorů DDD může vyžadovat přijetí nových technologií, rámců a architektonických přístupů. Integrace DDD se stávajícími systémy nebo staršími kódovými bázemi může být složitá a může vyžadovat přepracování nebo přepracování stávajícího kódu, aby byl v souladu s principy DDD.
  • Technické problémy, jako je výkon, škálovatelnost a udržovatelnost, musí být pečlivě řešeny, aby bylo zajištěno úspěšné přijetí DDD.
• Odolnost vůči změně :
  • Zavedení DDD může narazit na odpor členů týmu, kteří jsou zvyklí na tradiční vývojové přístupy nebo kteří DDD vnímají jako příliš složité či nepraktické.
  • Překonání odporu vůči změnám vyžaduje efektivní komunikaci, vzdělávání a vedení, které demonstruje výhody DDD a řeší obavy a skepticismus.
• Over-engineering :
  • Při aplikaci DDD existuje riziko nadměrného inženýrství, kdy se týmy příliš zaměřují na modelování komplexních doménových konceptů a zavádění zbytečných abstrakcí nebo složitostí. Dosažení správné rovnováhy mezi jednoduchostí a výrazností je zásadní, abyste se vyhnuli přílišné komplikaci návrhu a implementace.

Use-Cases of Domain-Driven Design (DDD)

• Finance a bankovnictví :
  • Ve finančním sektoru lze DDD použít k modelování složitých finančních nástrojů, transakcí a regulačních požadavků. Přesným znázorněním doménových konceptů, jako jsou účty, transakce a portfolia, pomáhá DDD zajistit integritu a konzistenci finančních systémů. Umožňuje také lepší řízení rizik, dodržování předpisů a výkaznictví.
• Elektronický obchod a maloobchod :
  • Platformy elektronického obchodu se často zabývají komplexními doménovými koncepty, jako jsou katalogy produktů, správa zásob, ceny a objednávky zákazníků. DDD může pomoci efektivně modelovat tyto koncepty a umožnit funkce, jako jsou personalizovaná doporučení, dynamické ceny a zjednodušené zpracování objednávek.
• Zdravotnictví a vědy o živé přírodě :
  • Ve zdravotnictví lze DDD použít k modelování záznamů pacientů, lékařských diagnóz, plánů léčby a pracovních postupů ve zdravotnictví. Přesným znázorněním doménových konceptů, jako je demografie pacientů, lékařská historie a klinické protokoly, umožňuje DDD vývoj robustních systémů elektronických zdravotních záznamů (EHR), lékařských zobrazovacích platforem a telemedicínských aplikací.
• Pojištění :
  • Pojišťovny spravují různé produkty, pojistky, nároky a procesy upisování. DDD může pomoci modelovat tyto komplexní doménové koncepty a umožnit funkce, jako je správa zásad, zpracování nároků, hodnocení rizik a pojistně-matematická analýza.
• Správa nemovitostí a majetku :
  • Správa nemovitostí a majetku zahrnuje vyřizování různých nemovitostí, pronájmy, nájemníky, požadavky na údržbu a finanční transakce. DDD může pomoci efektivně modelovat tyto koncepty domén a umožnit funkce, jako jsou výpisy nemovitostí, správa pronájmů, portály nájemců a sledování majetku.

Reálný příklad návrhu řízeného doménou (DDD)

Problémové prohlášení

Řekněme, že vyvíjíme aplikaci s názvem RideX. Systém umožňuje uživatelům požadovat jízdy, řidičům přijímat žádosti o jízdu a usnadňuje koordinaci jízd mezi uživateli a řidiči.

obsahuje python

Všudypřítomný jazyk

1. Uživatel : Týká se jednotlivců, kteří žádají o jízdu prostřednictvím platformy RideX.
2. Řidič : Týká se jednotlivců, kteří poskytují jízdy uživatelům prostřednictvím platformy RideX.
3. Žádost o jízdu : Představuje požadavek uživatele na jízdu s uvedením podrobností, jako je místo vyzvednutí, cíl a preference jízdy.
4. Jezdit : Představuje jednu instanci jízdy, včetně podrobností, jako jsou místa vyzvednutí a odevzdání, jízdné a doba trvání.
5. Stav jízdy : Představuje aktuální stav jízdy, například Vyžádáno, Přijato, Probíhá nebo Dokončeno.

Ohraničené kontexty

1. Kontext řízení jízdy : Zodpovědnost za správu životního cyklu jízd, včetně požadavků na jízdu, přiřazení jízd řidičům a aktualizací stavu jízd.
2. Kontext správy uživatelů : Zvládá ověřování uživatele, registraci a funkce specifické pro uživatele, jako je historie jízd a platební metody.
3. Kontext správy ovladačů : Spravuje ověření ovladače, registraci, stav dostupnosti a funkce specifické pro řidiče, jako jsou výdělky a hodnocení.

Entity a hodnotové objekty

1. Entita uživatele : Představuje registrovaného uživatele platformy RideX s vlastnostmi, jako je uživatelské ID, e-mail, heslo a platební údaje.
2. Entita řidiče : Představuje registrovaného řidiče na platformě RideX s vlastnostmi, jako je ID řidiče, podrobnosti o vozidle a stav řidiče.
3. Entita žádosti o jízdu : Představuje požadavek uživatele na jízdu, včetně vlastností, jako je ID požadavku, místo vyzvednutí, cíl a preference jízdy.
4. Jezdit Entita : Představuje jednu instanci jízdy, včetně vlastností, jako je ID jízdy, místa vyzvednutí a odevzdání, jízdné a stav jízdy.
5. Objekt hodnoty umístění : Představuje zeměpisnou polohu s vlastnostmi, jako je zeměpisná šířka a délka.

Agregáty

1. Jízdní agregát : Skládá se z entity Ride Entity jako agregovaného kořene spolu se souvisejícími entitami, jako jsou entity Ride Request, User a Driver. Ride Aggregate zapouzdřuje logiku pro řízení životního cyklu jízdy, včetně zpracování požadavků na jízdu, přidělování řidičů a aktualizace stavu jízdy.

Úložiště

1. Úložiště jízd : Poskytuje metody pro dotazování a ukládání entit souvisejících s jízdou, jako je načítání podrobností o jízdě, aktualizace stavu jízdy a ukládání dat souvisejících s jízdou do databáze.

Služby

1. Služba přidělování jízd : Zodpovědnost za přidělování dostupných řidičů žádostem o jízdu na základě faktorů, jako je dostupnost řidiče, blízkost místa vyzvednutí a preference uživatele.
2. Platební služba : Zvládá zpracování plateb za dokončené jízdy, výpočet jízdného, ​​zpracování plateb a aktualizaci platebních údajů pro uživatele a řidiče.

Doménové události

1. RideRequestedEvent : Představuje událost spuštěnou, když uživatel požádá o jízdu, obsahující informace, jako jsou podrobnosti žádosti o jízdu a ID uživatele.
2. RideAcceptedEvent : Představuje událost spuštěnou, když řidič přijme požadavek na jízdu, obsahující informace, jako je ID jízdy, ID řidiče a místo vyzvednutí.

Příklad scénáře

1. Uživatel žádající o jízdu : Uživatel požaduje jízdu poskytnutím místa vyzvednutí, cíle a preferencí jízdy. RideX vytvoří novou entitu požadavku na jízdu a spustí událost RideRequestedEvent.
2. Řidič přijímá jízdu : Řidič přijímá požadavek na jízdu z platformy RideX. RideX aktualizuje stav jízdy na Přijato, přiřadí řidiče k jízdě a spustí událost RideAcceptedEvent.
3. Ride In Progress : Uživatel a řidič koordinují jízdu, přičemž stav jízdy se změní z Přijato na Probíhá, jakmile řidič dorazí na místo vyzvednutí.
4. Dokončení jízdy : Po dosažení cíle se stav jízdy aktualizuje na Dokončeno. RideX vypočítá jízdné, zpracuje platbu a podle toho aktualizuje informace o platbě uživatele a řidiče.