Domain-Driven Design (DDD) je prístup k vývoju softvéru, ktorý sa zameriava na pochopenie a modelovanie problémovej domény, v ktorej softvérový systém funguje. Zdôrazňuje dôležitosť úzkej spolupráce s odborníkmi na túto oblasť, aby sa vyvinulo hlboké pochopenie zložitosti a zložitosti domény. DDD poskytuje súbor princípov, vzorov a praktík, ktoré pomáhajú vývojárom efektívne zachytiť a vyjadriť koncepty domén v ich softvérových návrhoch.

reťazcový formát v jazyku Java

Dôležité témy pre dizajn riadený doménou (DDD)

• Čo je to doménou riadený dizajn (DDD)?
• Dôležitosť znalosti domény
• Strategický dizajn v dizajne riadenom doménou (DDD)
• Vzory taktického dizajnu v dizajne riadenom doménou (DDD)
• Výhody dizajnu riadeného doménou (DDD)
• Výzvy dizajnu riadeného doménou (DDD)
• Prípady použitia dizajnu riadeného doménou (DDD)
• Reálny príklad dizajnu riadeného doménou (DDD)

Čo je to doménou riadený dizajn (DDD)?

doména

Vzťahuje sa na predmetnú oblasť alebo problémový priestor, na ktorý sa softvérový systém stavia. Zahŕňa skutočné koncepty, pravidlá a procesy, ktoré má softvér modelovať alebo podporovať. Napríklad v bankovej aplikácii doména zahŕňa pojmy ako účty, transakcie, zákazníci a predpisy súvisiace s bankovými operáciami.

Jazdené

Driven znamená, že návrh softvérového systému sa riadi alebo ovplyvňuje charakteristikami a požiadavkami domény. Inými slovami, rozhodnutia o dizajne sú založené na hlbokom porozumení domény a nie sú riadené výlučne technickými úvahami alebo detailmi implementácie.

Dizajn

Dizajn sa týka procesu vytvárania plánu alebo plánu pre softvérový systém. To zahŕňa rozhodnutia o tom, ako bude systém štruktúrovaný, ako budú rôzne komponenty interagovať a ako bude systém plniť svoje úlohy funkčné a nefunkčné požiadavky. V kontexte Domain-Driven Design sa dôraz kladie na navrhovanie softvéru spôsobom, ktorý presne odráža štruktúru a správanie domény.

Domain-Driven Design je koncept predstavený programátorom Eric Evans v roku 2004 vo svojej knihe Dizajn riadený doménou: Riešenie zložitosti v srdci softvéru

Dôležitosť znalosti domény

Predpokladajme, že sme navrhli softvér s využitím všetkých najnovších technológií a infraštruktúry a naša architektúra návrhu softvéru je úžasná, ale keď tento softvér uvedieme na trh, je to v konečnom dôsledku koncový používateľ, kto rozhodne, či je náš systém skvelý alebo nie. Taktiež ak systém nerieši obchodné potreby, potom je pre nikoho na nič. Bez ohľadu na to, ako pekne to vyzerá alebo aká dobrá je architektúra jeho infraštruktúry.

Podľa Eric Evans , Keď vyvíjame softvér, naše zameranie by nemalo byť primárne na technológiu, ale malo by byť primárne na podnikanie. zapamätaj si,

Nie je úlohou zákazníka vedieť, čo chce – Steve Jobs

Strategický dizajn v dizajne riadenom doménou (DDD)

Strategický dizajn v doménovom dizajne (DDD) sa zameriava na definovanie celkovej architektúry a štruktúry softvérového systému spôsobom, ktorý je v súlade s problémovou doménou. Zaoberá sa problémami na vysokej úrovni, ako napríklad ako organizovať koncepty domén, ako rozdeliť systém na spravovateľné časti a ako stanoviť jasné hranice medzi rôznymi komponentmi.

Pozrime sa na niektoré kľúčové koncepty v rámci strategického dizajnu v doménovom dizajne (DDD)

1. Ohraničené kontexty

• Ohraničený kontext predstavuje špecifickú oblasť v rámci celkovej problémovej domény, kde sa dôsledne uplatňuje konkrétny model alebo jazyk.
• Rôzne časti systému môžu mať pre rovnaké výrazy rôzne významy a ohraničený kontext definuje explicitné hranice, v rámci ktorých majú tieto výrazy špecifické významy.
• To umožňuje tímom vyvíjať modely, ktoré sú prispôsobené špecifickým kontextom bez zavádzania zmätku alebo nezrovnalostí.
• Ohraničené kontexty pomáhajú zvládnuť zložitosť rozdelením veľkej, komplexnej domény na menšie, lepšie spravovateľné časti.

2. Mapovanie kontextu

• Kontextové mapovanie je proces definovania vzťahov a interakcií medzi rôznymi ohraničenými kontextami.
• Zahŕňa identifikáciu oblastí prekrývania alebo integrácie medzi kontextami a vytváranie komunikačných kanálov a dohôd medzi nimi.
• Kontextové mapovanie pomáha zabezpečiť, aby rôzne časti systému mohli efektívne spolupracovať, pričom si stále zachovávajú jasné hranice medzi nimi.
• Existujú rôzne vzory a techniky pre kontextové mapovanie, ako napríklad partnerstvo, zdieľané jadro a zákazník-dodávateľ.

3. Strategické vzory

• Strategické vzory sú všeobecné pokyny alebo princípy pre organizáciu architektúry softvérového systému spôsobom, ktorý je v súlade s problémovou doménou.
• Tieto vzory pomáhajú riešiť bežné výzvy pri navrhovaní zložitých systémov a poskytujú osvedčené prístupy na efektívne štruktúrovanie systému.
• Príklady strategických vzorov zahŕňajú agregáty, doménové udalosti a protikorupčnú vrstvu.
• Tieto vzory poskytujú riešenia opakujúcich sa problémov v dizajne riadenom doménou a pomáhajú zabezpečiť, aby architektúra systému presne odrážala základné koncepty domény.

4. Zdieľané jadro

• Zdieľané jadro je strategický vzor, ​​ktorý zahŕňa identifikáciu oblastí spoločných medzi rôznymi ohraničenými kontextmi a vytvorenie zdieľanej podmnožiny modelu domény, ktorý sa používa vo viacerých kontextoch.
• Táto zdieľaná podmnožina alebo jadro pomáha uľahčiť spoluprácu a integráciu medzi kontextami a zároveň umožňuje každému kontextu zachovať si svoj vlastný odlišný model.
• Zdieľané jadro by sa malo používať uvážlivo, pretože zavádza závislosti medzi kontextami a môže viesť k spájaniu, ak nie je spravované opatrne.

5. Anti-Corruption Layer (ACL)

• Protikorupčná vrstva je ďalším strategickým vzorom, ktorý pomáha chrániť systém pred vplyvom externých alebo starších systémov, ktoré používajú rôzne modely alebo jazyky.
• ACL funguje ako prekladová vrstva medzi externým systémom a modelom základnej domény a podľa potreby transformuje údaje a správy, aby sa zabezpečila kompatibilita.
• To umožňuje, aby model základnej domény zostal čistý a zameraný na problémovú doménu, pričom sa podľa potreby stále integruje s externými systémami.

6. Všadeprítomný jazyk

Všadeprítomný jazyk sa vzťahuje na zdieľanú slovnú zásobu alebo jazyk, ktorý sa používa konzistentne a univerzálne medzi všetkými zainteresovanými stranami zapojenými do vývoja softvérového systému. Tento jazyk pozostáva z výrazov, fráz a konceptov, ktoré presne reprezentujú doménové znalosti a koncepty.

Niektoré z kľúčových princípov všadeprítomného jazyka sú:

• Zdieľané porozumenie : Primárnym cieľom Ubiquitous Language je vytvoriť spoločné chápanie problémovej domény medzi všetkými členmi vývojového tímu, vrátane vývojárov, doménových expertov, obchodných analytikov a zainteresovaných strán. Použitím spoločného jazyka môžu všetci zúčastnení komunikovať efektívnejšie a presnejšie sprostredkovať doménové koncepty a požiadavky.
• Konzistentnosť a jasnosť : Všadeprítomný jazyk podporuje konzistentnosť a jasnosť v komunikácii pomocou presnej a jednoznačnej terminológie. Každý výraz alebo fráza v jazyku by mala mať jasný a dohodnutý význam,
• Zosúladenie s obchodnými konceptmi : Jazyk používaný v DDD by mal byť v úzkom súlade s terminológiou a konceptmi používanými v obchodnej doméne. Mal by odrážať spôsob, akým doménoví experti uvažujú a hovoria o problémovej doméne, čím sa zabezpečí, že softvér presne reprezentuje koncepty a procesy v reálnom svete.
• Evolučná povaha : Všadeprítomný jazyk nie je statický, ale časom sa vyvíja, keď tím získava hlbšie pochopenie domény a menia sa požiadavky. Mal by sa prispôsobiť tak, aby odrážal nové poznatky, objavy alebo zmeny v obchodných prioritách, čím sa zabezpečí, že jazyk zostane relevantný a aktuálny počas celého procesu vývoja.

Vzory taktického dizajnu v dizajne riadenom doménou (DDD)

V Domain-Driven Design (DDD) sú taktické vzory dizajnu špecifické stratégie alebo techniky používané na štruktúrovanie a organizovanie modelu domény v rámci softvérového systému. Tieto vzory pomáhajú vývojárom efektívne zachytiť zložitosť domény a zároveň podporujú udržiavateľnosť, flexibilitu a škálovateľnosť.

Pozrime sa na niektoré z kľúčových vzorov taktického dizajnu v DDD:

podreťazec v bash

1. Entita

Entita je objekt domény, ktorý má odlišnú identitu a životný cyklus. Entity sú charakteristické svojimi jedinečnými identifikátormi a premenlivým stavom. Zapuzdrujú správanie a údaje súvisiace s konkrétnym konceptom v rámci domény.

Napríklad v bankovej aplikácii aBankAccount>subjekt môže mať vlastnosti, ako je číslo účtu, zostatok a vlastník, spolu s metódami vkladu, výberu alebo prevodu finančných prostriedkov.

2. Objekt hodnoty

Hodnotový objekt je doménový objekt, ktorý predstavuje koncepčne nemennú hodnotu. Na rozdiel od entít nemajú hodnotové objekty odlišnú identitu a zvyčajne sa používajú na reprezentáciu atribútov alebo vlastností entít. Hodnotové objekty sú rovnocenne porovnateľné skôr na základe ich vlastností než identity.

Napríklad aMoney>objekt hodnoty môže predstavovať konkrétnu sumu meny, ktorá zahŕňa vlastnosti, ako je typ meny a suma.

3. Agregát

• Agregát je zhluk doménových objektov, s ktorými sa na účely konzistentnosti údajov a transakčnej integrity zaobchádza ako s jednou jednotkou.
• Agregáty pozostávajú z jednej alebo viacerých entít a hodnotových objektov, pričom jedna entita je označená ako agregovaný koreň.
• Koreň agregátu slúži ako vstupný bod pre prístup a úpravu vnútorného stavu agregátu.
• Agregáty presadzujú hranice konzistencie v rámci modelu domény, čím zaisťujú, že zmeny súvisiacich objektov sú vykonávané atomicky.

Napríklad v systéme elektronického obchodu, anOrder>agregát môže pozostávať z entít ako naprOrderItem>aCustomer>, sOrder>entita slúžiaca ako súhrnný koreň.

4. Úložisko

• Úložisko je mechanizmus na abstrahovanie prístupu k údajom a logiky pretrvávania z modelu domény.
• Repozitáre poskytujú štandardizované rozhranie na dopytovanie a ukladanie doménových objektov, pričom skrývajú podrobnosti o tom, ako sa údaje získavajú alebo ukladajú. Repozitáre zapuzdrujú logiku prekladu medzi objektmi domény a základnými mechanizmami ukladania údajov, ako sú databázy alebo externé služby.
• Odpojením modelu domény od problémov s prístupom k údajom umožňujú úložiská väčšiu flexibilitu a udržiavateľnosť.

Napríklad aCustomerRepository>môže poskytnúť metódy na dopytovanie a ukladanieCustomer>subjektov.

5. Fabrika

• Továreň je a tvorivý vzor používa sa na zapuzdrenie logiky vytvárania inštancií komplexných doménových objektov. Továrne abstrahujú proces vytvárania objektov a umožňujú klientom vytvárať objekty bez toho, aby museli poznať detaily ich konštrukcie.
• Továrne sú obzvlášť užitočné na vytváranie objektov, ktoré vyžadujú komplexnú inicializačnú logiku alebo zahŕňajú viacero krokov.

Napríklad aProductFactory>môže byť zodpovedný za vytváranie inštanciíProduct>entity s predvolenými konfiguráciami.

6. Služba

• Služba je doménový objekt, ktorý predstavuje správanie alebo operáciu, ktorá prirodzene nepatrí žiadnej konkrétnej entite alebo hodnotovému objektu.
• Služby zapuzdrujú doménovú logiku, ktorá funguje na viacerých objektoch alebo organizuje interakcie medzi objektmi.
• Služby sú zvyčajne bez stavu a zameriavajú sa na vykonávanie špecifických úloh alebo presadzovanie pravidiel domény.

Napríklad anOrderService>môže poskytnúť metódy spracovania objednávok, uplatňovania zliav a výpočtu nákladov na dopravu.

Výhody dizajnu riadeného doménou (DDD)

• Zdieľané porozumenie :
  • Podporuje spoluprácu medzi doménovými expertmi, vývojármi a zainteresovanými stranami.
  • Podporou spoločného chápania problémovej domény prostredníctvom všadeprítomného jazyka môžu tímy komunikovať efektívnejšie a zabezpečiť, aby softvér presne odrážal potreby a požiadavky podniku.
• Zamerajte sa na hlavnú doménu :
  • Pomáha tímom identifikovať a uprednostňovať základnú doménu aplikácie – oblasti systému, ktoré poskytujú podniku najväčšiu hodnotu. Zameraním vývojového úsilia na hlavnú doménu môžu tímy poskytovať funkcie, ktoré priamo riešia obchodné ciele a odlišujú softvér od konkurencie.
• Odolnosť voči zmene :
  • Kladie dôraz na navrhovanie softvérových systémov, ktoré sú odolné voči zmenám, modelovaním domény spôsobom, ktorý odráža prirodzené zložitosti a neistoty problémovej domény.
  • Prijatím zmeny ako prirodzenej súčasti vývoja softvéru môžu tímy efektívnejšie reagovať na meniace sa obchodné potreby a podmienky na trhu.
• Jasné oddelenie obáv :
  • DDD podporuje jasné oddelenie obáv medzi doménovou logikou, problémami infraštruktúry a používateľským rozhraním. Izoláciou doménovej logiky od technických detailov a problémov infraštruktúry môžu tímy udržiavať čistý a zameraný doménový model, ktorý je nezávislý od konkrétnych implementačných detailov alebo technologických volieb.
• Vylepšená testovateľnosť :
  • Podporuje používanie doménových objektov s dobre definovanými hranicami a správaním, čo uľahčuje písanie lepších a cielených testov, ktoré overujú správnosť doménovej logiky.
  • Navrhovaním softvérových systémov s ohľadom na testovateľnosť môžu tímy zabezpečiť, že zmeny kódovej základne budú bezpečné a predvídateľné, čím sa zníži riziko zavedenia regresií alebo neúmyselných vedľajších účinkov.
• Podpora komplexných obchodných pravidiel :
  • Poskytuje vzory a techniky na modelovanie a implementáciu komplexných obchodných pravidiel a pracovných postupov v rámci modelu domény.
  • Explicitným zastúpením obchodných pravidiel v modeli domény môžu tímy zabezpečiť, aby softvér presne odrážal zložitosť obchodnej domény a presadzoval obmedzenia a požiadavky špecifické pre danú doménu.
• Súlad s obchodnými cieľmi :
  • V konečnom dôsledku sa zameriava na zosúladenie úsilia o vývoj softvéru so strategickými cieľmi a zámermi podniku. Zameraním sa na pochopenie a modelovanie problémovej domény môžu tímy dodávať softvérové ​​riešenia, ktoré priamo podporujú obchodné ciele, podporujú inovácie a vytvárajú hodnotu pre zainteresované strany a koncových používateľov.

Výzvy dizajnu riadeného doménou (DDD)

• Zložitosť :
  • DDD môže priniesť zložitosť, najmä vo veľkých a zložitých doménach.
  • Presné modelovanie zložitých obchodných domén si vyžaduje hlboké pochopenie domény a môže zahŕňať riešenie nejednoznačnosti a neistoty. Efektívne riadenie tejto zložitosti si vyžaduje starostlivé plánovanie, spoluprácu a odborné znalosti.
• Všadeprítomné osvojenie jazyka :
  • Vytvorenie a udržiavanie všadeprítomného jazyka – zdieľanej slovnej zásoby, ktorá presne reprezentuje koncepty domény – môže byť náročné. Vyžaduje si to spoluprácu medzi vývojármi a odborníkmi na domény, aby sa identifikovali a odsúhlasili termíny a významy domény.
  • Dosiahnutie konsenzu o všadeprítomnom jazyku môže vyžadovať prekonanie komunikačných bariér a zosúladenie rozdielov v terminológii a perspektívach.
• Zarovnanie ohraničeného kontextu :
  • Vo veľkých a zložitých doménach môžu mať rôzne časti domény odlišné modely a ohraničené kontexty. Zosúladenie týchto ohraničených kontextov a zabezpečenie konzistentnosti medzi nimi môže byť náročné.
  • Vyžaduje si to jasnú komunikáciu, spoluprácu a koordináciu medzi tímami pracujúcimi na rôznych častiach domény, aby sa predišlo nezrovnalostiam a konfliktom.
• Technická zložitosť :
  • Účinná implementácia princípov a vzorov DDD môže vyžadovať prijatie nových technológií, rámcov a architektonických prístupov. Integrácia DDD s existujúcimi systémami alebo starými kódovými základňami môže byť zložitá a môže vyžadovať prerobenie alebo prerobenie existujúceho kódu, aby bol v súlade s princípmi DDD.
  • Technické výzvy, ako je výkon, škálovateľnosť a udržiavateľnosť, sa musia starostlivo riešiť, aby sa zabezpečilo úspešné prijatie DDD.
• Odolnosť voči zmene :
  • Zavedenie DDD môže naraziť na odpor členov tímu, ktorí sú zvyknutí na tradičné rozvojové prístupy alebo ktorí vnímajú DDD ako príliš zložité alebo nepraktické.
  • Prekonanie odporu voči zmenám si vyžaduje efektívnu komunikáciu, vzdelávanie a vedenie, aby sa demonštrovali výhody DDD a riešili obavy a skepticizmus.
• Nadmerné inžinierstvo :
  • Existuje riziko nadmerného inžinierstva pri aplikácii DDD, kde sa tímy príliš zameriavajú na modelovanie komplexných doménových konceptov a zavádzanie zbytočných abstrakcií alebo zložitosti. Dosiahnutie správnej rovnováhy medzi jednoduchosťou a výraznosťou je kľúčové, aby ste sa vyhli príliš komplikovanému návrhu a implementácii.

Prípady použitia dizajnu riadeného doménou (DDD)

• Financie a bankovníctvo :
  • Vo finančnom sektore možno DDD použiť na modelovanie zložitých finančných nástrojov, transakcií a regulačných požiadaviek. Presným znázornením doménových konceptov, ako sú účty, transakcie a portfóliá, pomáha DDD zabezpečiť integritu a konzistentnosť finančných systémov. Umožňuje tiež lepšie riadenie rizík, dodržiavanie predpisov a podávanie správ.
• Elektronický obchod a maloobchod :
  • Platformy elektronického obchodu sa často zaoberajú komplexnými doménovými konceptmi, ako sú katalógy produktov, správa zásob, ceny a objednávky zákazníkov. DDD môže pomôcť efektívne modelovať tieto koncepty tým, že umožňuje funkcie, ako sú personalizované odporúčania, dynamické ceny a zjednodušené spracovanie objednávok.
• Zdravotníctvo a vedy o živote :
  • V zdravotníctve možno DDD použiť na modelovanie záznamov pacientov, lekárskych diagnóz, plánov liečby a pracovných postupov v oblasti zdravotnej starostlivosti. Presným znázornením doménových konceptov, ako je demografia pacientov, anamnéza a klinické protokoly, umožňuje DDD vývoj robustných systémov elektronických zdravotných záznamov (EHR), platforiem pre lekárske zobrazovanie a telemedicínskych aplikácií.
• poistenie :
  • Poisťovne riadia rôzne produkty, poistky, nároky a upisovacie procesy. DDD môže pomôcť modelovať tieto komplexné doménové koncepty a umožniť funkcie, ako je správa zásad, spracovanie nárokov, hodnotenie rizík a poistno-matematická analýza.
• Správa nehnuteľností a majetku :
  • Správa nehnuteľností a majetku zahŕňa vybavovanie rôznych nehnuteľností, prenájmov, nájomníkov, požiadaviek na údržbu a finančných transakcií. DDD môže pomôcť efektívne modelovať tieto koncepty domén a umožniť funkcie, ako sú zoznamy nehnuteľností, správa prenájmu, portály nájomníkov a sledovanie majetku.

Reálny príklad dizajnu riadeného doménou (DDD)

Vyhlásenie o probléme

Povedzme, že vyvíjame aplikáciu s názvom RideX. Systém umožňuje užívateľom požadovať jazdy, vodičom akceptovať žiadosti o jazdu a uľahčuje koordináciu jázd medzi užívateľmi a vodičmi.

dovozný mravec

Všadeprítomný jazyk

1. Používateľ : Vzťahuje sa na jednotlivcov, ktorí žiadajú o jazdu prostredníctvom platformy RideX.
2. Vodič : Vzťahuje sa na jednotlivcov, ktorí poskytujú jazdy používateľom prostredníctvom platformy RideX.
3. Žiadosť o jazdu : Predstavuje požiadavku používateľa na jazdu a špecifikuje podrobnosti, ako je miesto vyzdvihnutia, cieľ a preferencie jazdy.
4. Jazdite : Predstavuje jeden prípad jazdy vrátane podrobností, ako sú miesta vyzdvihnutia a odovzdania, cestovné a trvanie.
5. Stav jazdy : Predstavuje aktuálny stav jazdy, napríklad Vyžiadaná, Prijatá, Prebieha alebo Dokončená.

Ohraničené kontexty

1. Kontext riadenia jazdy : Zodpovedá za riadenie životného cyklu jázd vrátane žiadostí o jazdu, pridelenia jázd vodičom a aktualizácií stavu jázd.
2. Kontext správy používateľov : Rieši autentifikáciu používateľa, registráciu a funkcie špecifické pre používateľa, ako je história jázd a spôsoby platby.
3. Kontext správy ovládačov : Spravuje overenie vodiča, registráciu, stav dostupnosti a funkcie špecifické pre vodiča, ako sú zárobky a hodnotenia.

Entity a Hodnotové objekty

1. Entita používateľa : Predstavuje registrovaného používateľa platformy RideX s vlastnosťami ako ID používateľa, e-mail, heslo a informácie o platbe.
2. Entita vodiča : Predstavuje registrovaného vodiča na platforme RideX s vlastnosťami ako ID vodiča, podrobnosti o vozidle a stav vodiča.
3. Subjekt žiadosti o jazdu : Predstavuje žiadosť používateľa o jazdu vrátane vlastností, ako je ID žiadosti, miesto vyzdvihnutia, cieľ a preferencie jazdy.
4. Entita jazdy : Predstavuje jednu inštanciu jazdy vrátane vlastností, ako je ID jazdy, miesta vyzdvihnutia a odovzdania, cestovné a stav jazdy.
5. Objekt hodnoty polohy : Predstavuje geografickú polohu s vlastnosťami ako zemepisná šírka a dĺžka.

Agregáty

1. Jazdný agregát : Pozostáva z entity Jazdy ako súhrnného koreňa spolu so súvisiacimi entitami, ako sú entity Žiadosť o jazdu, Používateľ a Vodič. Ride Aggregate zahŕňa logiku riadenia životného cyklu jazdy, vrátane spracovania žiadostí o jazdu, priraďovania vodičov a aktualizácie stavu jazdy.

Úložisko

1. Úložisko jázd : Poskytuje metódy na dopytovanie a ukladanie entít súvisiacich s jazdou, ako je načítanie podrobností o jazde, aktualizácia stavu jazdy a ukladanie údajov súvisiacich s jazdou do databázy.

Služby

1. Služba prideľovania jázd : Zodpovedá za priradenie dostupných vodičov k žiadostiam o jazdu na základe faktorov, ako je dostupnosť vodiča, blízkosť miesta vyzdvihnutia a preferencie používateľov.
2. Platobná služba : Zaoberá sa spracovaním platieb za dokončené jazdy, výpočtom cestovného, ​​spracovaním platieb a aktualizáciou informácií o platbách pre používateľa a vodiča.

Doménové udalosti

1. RideRequestedEvent : Predstavuje udalosť spustenú, keď používateľ požiada o jazdu, a obsahuje informácie, ako sú podrobnosti žiadosti o jazdu a ID používateľa.
2. RideAcceptedEvent : Predstavuje udalosť spustenú, keď vodič prijme požiadavku na jazdu, ktorá obsahuje informácie ako ID jazdy, ID vodiča a miesto vyzdvihnutia.

Príklad scenára

1. Používateľ žiadajúci o jazdu : Používateľ požaduje jazdu zadaním miesta vyzdvihnutia, cieľa a preferencií jazdy. RideX vytvorí novú entitu žiadosti o jazdu a spustí udalosť RideRequestedEvent.
2. Vodič prijímajúci jazdu : Vodič prijme požiadavku na jazdu z platformy RideX. RideX aktualizuje stav jazdy na Accepted, priradí vodiča k jazde a spustí RideAcceptedEvent.
3. Ride In Progress : Používateľ a vodič koordinujú jazdu, pričom stav jazdy sa zmení z Akceptované na Prebieha, keď vodič dosiahne miesto vyzdvihnutia.
4. Dokončenie jazdy : Po dosiahnutí cieľa sa stav jazdy aktualizuje na Dokončené. RideX vypočíta cestovné, spracuje platbu a podľa toho aktualizuje informácie o platbe používateľa a vodiča.