Domensko usmerjeno načrtovanje (DDD) je pristop k razvoju programske opreme, ki se osredotoča na razumevanje in modeliranje problemske domene, znotraj katere deluje programski sistem. Poudarja pomen tesnega sodelovanja s strokovnjaki za področje, da bi razvili globoko razumevanje zapletenosti in zapletenosti področja. DDD ponuja nabor načel, vzorcev in praks, ki razvijalcem pomagajo pri učinkovitem zajemanju in izražanju domenskih konceptov v njihovih načrtih programske opreme.

pretvorba niza v int v Javi

Pomembne teme za načrtovanje, ki temelji na domeni (DDD)

• Kaj je Domain-Driven Design (DDD)?
• Pomen znanja o domeni
• Strateško načrtovanje v domensko usmerjenem oblikovanju (DDD)
• Taktični vzorci načrtovanja v domensko vodenem načrtovanju (DDD)
• Prednosti oblikovanja, ki temelji na domeni (DDD)
• Izzivi domensko vodenega oblikovanja (DDD)
• Primeri uporabe domensko vodenega oblikovanja (DDD)
• Realni primer načrtovanja, ki temelji na domeni (DDD)

Kaj je Domain-Driven Design (DDD)?

Domena

Nanaša se na predmetno področje ali problemski prostor, za reševanje katerega se gradi sistem programske opreme. Zajema koncepte, pravila in procese iz resničnega sveta, ki naj bi jih programska oprema modelirala ali podpirala. Na primer, v bančni aplikaciji domena vključuje koncepte, kot so računi, transakcije, stranke in predpisi, povezani z bančnimi operacijami.

Pognan

Vonjeno pomeni, da je zasnova programskega sistema vodena ali nanjo vplivajo značilnosti in zahteve domene. Z drugimi besedami, oblikovalske odločitve temeljijo na globokem razumevanju domene, namesto da bi jih vodili izključno tehnični vidiki ali podrobnosti izvedbe.

Oblikovanje

Oblikovanje se nanaša na postopek ustvarjanja načrta ali načrta za programski sistem. To vključuje odločitve o tem, kako bo sistem strukturiran, kako bodo različne komponente medsebojno delovale in kako bo sistem izpolnjeval svoje delujoč in nefunkcionalen zahteve. V okviru domensko vodenega oblikovanja je poudarek na oblikovanju programske opreme na način, ki natančno odraža strukturo in obnašanje domene.

Domensko vodeno oblikovanje je koncept, ki ga uvede programer Eric Evans leta 2004 v svoji knjigi Oblikovanje, ki temelji na domeni: reševanje kompleksnosti v središču programske opreme

Pomen znanja o domeni

Recimo, da smo zasnovali programsko opremo z uporabo vseh najnovejših tehnoloških skladov in infrastrukture in da je naša arhitektura zasnove programske opreme neverjetna, toda ko to programsko opremo izdamo na trg, je na koncu končni uporabnik tisti, ki odloči, ali je naš sistem odličen ali ne. Tudi če sistem ne rešuje poslovnih potreb, potem nikomur ne koristi. Ne glede na to, kako lep je videti ali kako dobra arhitektura je njegova infrastruktura.

Po navedbah Eric Evans , Ko razvijamo programsko opremo, se ne smemo osredotočati predvsem na tehnologijo, ampak predvsem na posel. Ne pozabite,

Naloga stranke ni vedeti, kaj hoče – Steve Jobs

Strateško načrtovanje v domensko usmerjenem oblikovanju (DDD)

Strateško načrtovanje v domensko vodenem načrtovanju (DDD) se osredotoča na definiranje celotne arhitekture in strukture programskega sistema na način, ki je usklajen s problematično domeno. Obravnava vprašanja na visoki ravni, kot so, kako organizirati koncepte domene, kako razdeliti sistem na obvladljive dele in kako vzpostaviti jasne meje med različnimi komponentami.

Oglejmo si nekaj ključnih konceptov znotraj strateškega oblikovanja v domensko usmerjenem oblikovanju (DDD)

1. Omejeni konteksti

• Omejen kontekst predstavlja določeno področje znotraj splošne problemske domene, kjer se dosledno uporablja določen model ali jezik.
• Različni deli sistema imajo lahko različne pomene za iste izraze, omejeni kontekst pa definira eksplicitne meje, znotraj katerih imajo ti izrazi posebne pomene.
• To ekipam omogoča, da razvijejo modele, ki so prilagojeni specifičnim kontekstom brez vnašanja zmede ali nedoslednosti.
• Omejeni konteksti pomagajo obvladovati kompleksnost tako, da razčlenijo veliko, kompleksno domeno na manjše, bolj obvladljive dele.

2. Preslikava konteksta

• Preslikava konteksta je postopek definiranja odnosov in interakcij med različnimi omejenimi konteksti.
• Vključuje prepoznavanje področij prekrivanja ali integracije med konteksti ter vzpostavljanje komunikacijskih kanalov in dogovorov med njimi.
• Preslikava konteksta pomaga zagotoviti, da lahko različni deli sistema učinkovito sodelujejo, medtem ko še vedno ohranja jasne meje med njimi.
• Obstajajo različni vzorci in tehnike za preslikavo konteksta, kot so partnerstvo, skupno jedro in stranka-dobavitelj.

numpy pika

3. Strateški vzorci

• Strateški vzorci so splošne smernice ali načela za organizacijo arhitekture programskega sistema na način, ki je usklajen s problemsko domeno.
• Ti vzorci pomagajo pri reševanju pogostih izzivov pri oblikovanju kompleksnih sistemov in zagotavljajo preizkušene pristope za učinkovito strukturiranje sistema.
• Primeri strateških vzorcev vključujejo agregate, dogodke v domeni in protikorupcijsko plast.
• Ti vzorci nudijo rešitve za ponavljajoče se težave pri oblikovanju, ki temelji na domeni, in pomagajo zagotoviti, da arhitektura sistema natančno odraža koncepte osnovne domene.

4. Jedro v skupni rabi

• Jedro v skupni rabi je strateški vzorec, ki vključuje prepoznavanje skupnih področij med različnimi omejenimi konteksti in vzpostavitev skupne podmnožice domenskega modela, ki ga uporablja več kontekstov.
• Ta podmnožica ali jedro v skupni rabi pomaga olajšati sodelovanje in integracijo med konteksti, hkrati pa vsakemu kontekstu še vedno omogoča, da vzdržuje svoj lasten ločen model.
• Jedro v skupni rabi je treba uporabljati preudarno, saj uvaja odvisnosti med konteksti in lahko vodi do spajanja, če z njim ne upravljate skrbno.

5. Protikorupcijska plast (ACL)

• Protikorupcijska plast je še en strateški vzorec, ki pomaga zaščititi sistem pred vplivom zunanjih ali podedovanih sistemov, ki uporabljajo različne modele ali jezike.
• ACL deluje kot prevajalska plast med zunanjim sistemom in osrednjim modelom domene ter preoblikuje podatke in sporočila, kot je potrebno, da se zagotovi združljivost.
• To omogoča, da osrednji model domene ostane čist in osredotočen na problemsko domeno, medtem ko se po potrebi še vedno integrira z zunanjimi sistemi.

6. Vseprisotni jezik

Vseprisotni jezik se nanaša na skupni besednjak ali jezik, ki se dosledno in univerzalno uporablja pri vseh deležnikih, vključenih v razvoj programskega sistema. Ta jezik je sestavljen iz izrazov, fraz in konceptov, ki natančno predstavljajo znanje in koncepte področja.

Nekatera ključna načela vseprisotnega jezika so:

• Skupno razumevanje : Primarni cilj Ubiquitous Language je vzpostaviti skupno razumevanje domene problema med vsemi člani razvojne ekipe, vključno z razvijalci, strokovnjaki za področje, poslovnimi analitiki in deležniki. Z uporabo skupnega jezika lahko vsi vpleteni učinkoviteje komunicirajo in natančneje posredujejo pojme in zahteve domene.
• Doslednost in jasnost : Ubiquitous Language spodbuja doslednost in jasnost v komunikaciji z uporabo natančne in nedvoumne terminologije. Vsak izraz ali fraza v jeziku mora imeti jasen in dogovorjen pomen,
• Uskladitev s poslovnimi koncepti : Jezik, uporabljen v DDD, mora biti tesno usklajen s terminologijo in koncepti, ki se uporabljajo v poslovni domeni. Odražati mora način, na katerega strokovnjaki za področje razmišljajo in govorijo o problematičnem področju, ter zagotavljati, da programska oprema natančno predstavlja koncepte in procese iz resničnega sveta.
• Evolucijska narava : Ubiquitous Language ni statičen, ampak se sčasoma razvija, ko ekipa pridobi globlje razumevanje domene in ko se zahteve spreminjajo. Prilagoditi se mora tako, da bo odražal nova spoznanja, odkritja ali spremembe poslovnih prednostnih nalog, s čimer bo zagotovil, da jezik ostane ustrezen in posodobljen v celotnem razvojnem procesu.

Taktični vzorci načrtovanja v domensko usmerjenem načrtovanju (DDD)

Pri načrtovanju, ki temelji na domeni (DDD), so taktični vzorci načrtovanja posebne strategije ali tehnike, ki se uporabljajo za strukturiranje in organizacijo modela domene znotraj sistema programske opreme. Ti vzorci razvijalcem pomagajo učinkovito zajeti kompleksnost domene, hkrati pa spodbujajo vzdržljivost, prilagodljivost in razširljivost.

Oglejmo si nekaj ključnih taktičnih oblikovalskih vzorcev v DDD:

1. Entiteta

Entiteta je predmet domene, ki ima ločeno identiteto in življenjski cikel. Za entitete so značilni edinstveni identifikatorji in spremenljivo stanje. Enkapsulirajo vedenje in podatke, povezane z določenim konceptom znotraj domene.

Na primer, v bančni aplikaciji, aBankAccount>entiteta ima lahko lastnosti, kot so številka računa, stanje in lastnik, skupaj z metodami za polog, dvig ali prenos sredstev.

2. Vrednostni predmet

Vrednostni objekt je domenski objekt, ki predstavlja konceptualno nespremenljivo vrednost. Za razliko od entitet objekti vrednosti nimajo posebne identitete in se običajno uporabljajo za predstavitev atributov ali lastnosti entitet. Vrednostni objekti so primerljivi glede enakosti na podlagi svojih lastnosti in ne na podlagi identitete.

Na primer, aMoney>predmet vrednosti lahko predstavlja določeno količino valute, ki vsebuje lastnosti, kot sta vrsta in znesek valute.

3. Agregat

• Agregat je gruča predmetov domene, ki se obravnavajo kot ena enota zaradi doslednosti podatkov in celovitosti transakcije.
• Agregati so sestavljeni iz ene ali več entitet in objektov vrednosti, pri čemer je ena entiteta označena kot koren agregata.
• Koren agregata služi kot vstopna točka za dostop in spreminjanje notranjega stanja agregata.
• Agregati uveljavljajo meje skladnosti znotraj modela domene in zagotavljajo, da se spremembe povezanih objektov izvajajo atomsko.

Na primer, v sistemu e-trgovine, anOrder>agregat je lahko sestavljen iz entitet, kot jeOrderItem>inCustomer>, zOrder>entiteta, ki služi kot agregatni koren.

4. Repozitorij

• Repozitorij je mehanizem za abstrahiranje dostopa do podatkov in logike obstojnosti iz modela domene.
• Repozitoriji zagotavljajo standardiziran vmesnik za poizvedovanje in shranjevanje predmetov domene, pri čemer se skrivajo podrobnosti o tem, kako se podatki pridobivajo ali shranjujejo. Repozitoriji zajemajo logiko za prevajanje med predmeti domene in osnovnimi mehanizmi za shranjevanje podatkov, kot so baze podatkov ali zunanje storitve.
• Z ločevanjem domenskega modela od težav z dostopom do podatkov repozitoriji omogočajo večjo prilagodljivost in vzdržljivost.

Na primer, aCustomerRepository>lahko zagotovi metode za poizvedovanje in shranjevanjeCustomer>entitete.

5. Tovarna

• Tovarna je a ustvarjalni vzorec uporablja za enkapsulacijo logike za ustvarjanje primerkov kompleksnih predmetov domene. Tovarne abstrahirajo proces instanciranja objekta, kar strankam omogoča ustvarjanje predmetov, ne da bi morali poznati podrobnosti njihove konstrukcije.
• Tovarne so še posebej uporabne za ustvarjanje objektov, ki zahtevajo kompleksno logiko inicializacije ali vključujejo več korakov.

Na primer, aProductFactory>morda odgovoren za ustvarjanje primerkovProduct>entitete s privzetimi konfiguracijami.

6. Storitev

• Storitev je objekt domene, ki predstavlja vedenje ali operacijo, ki naravno ne pripada nobeni določeni entiteti ali objektu vrednosti.
• Storitve zajemajo logiko domene, ki deluje na več predmetih ali orkestrira interakcije med objekti.
• Storitve so običajno brez stanja in se osredotočajo na izvajanje določenih nalog ali uveljavljanje pravil domene.

Na primer, anOrderService>lahko ponudi metode za obdelavo naročil, uporabo popustov in izračun stroškov pošiljanja.

Prednosti oblikovanja, ki temelji na domeni (DDD)

• Skupno razumevanje :
  • Spodbuja sodelovanje med strokovnjaki na področju, razvijalci in zainteresiranimi stranmi.
  • S spodbujanjem skupnega razumevanja problematičnega področja prek vseprisotnega jezika lahko ekipe učinkoviteje komunicirajo in zagotovijo, da programska oprema natančno odraža potrebe in zahteve podjetja.
• Osredotočite se na osnovno domeno :
  • Pomaga skupinam prepoznati in določiti prioriteto osrednje domene aplikacije – področja sistema, ki zagotavljajo največjo vrednost podjetju. Z osredotočenjem razvojnih prizadevanj na osrednjo domeno lahko ekipe zagotovijo funkcionalnost, ki neposredno obravnava poslovne cilje in programsko opremo razlikuje od konkurentov.
• Odpornost na spremembe :
  • Poudarja oblikovanje sistemov programske opreme, ki so odporni na spremembe z modeliranjem domene na način, ki odraža inherentno kompleksnost in negotovost problematične domene.
  • Če sprejmejo spremembe kot naravni del razvoja programske opreme, se lahko ekipe učinkoviteje odzivajo na razvijajoče se poslovne potrebe in tržne razmere.
• Jasna ločitev skrbi :
  • DDD spodbuja jasno ločevanje pomislekov med domensko logiko, pomisleki glede infrastrukture in pomisleki glede uporabniškega vmesnika. Z izolacijo logike domene od tehničnih podrobnosti in skrbi glede infrastrukture lahko ekipe vzdržujejo čist in osredotočen model domene, ki je neodvisen od posebnih podrobnosti izvedbe ali tehnoloških odločitev.
• Izboljšana preizkušljivost :
  • Spodbuja uporabo predmetov domene z dobro definiranimi mejami in vedenjem, kar olajša pisanje boljših in osredotočenih testov, ki preverjajo pravilnost logike domene.
  • Z načrtovanjem programskih sistemov z mislijo na preizkušljivost lahko ekipe zagotovijo, da so spremembe kodne baze varne in predvidljive, kar zmanjša tveganje za uvedbo regresij ali nenamernih stranskih učinkov.
• Podpora za kompleksna poslovna pravila :
  • Zagotavlja vzorce in tehnike za modeliranje in implementacijo kompleksnih poslovnih pravil in delovnih tokov znotraj modela domene.
  • Z izrecno predstavitvijo poslovnih pravil v modelu domene lahko ekipe zagotovijo, da programska oprema natančno odraža zapletenost poslovne domene in uveljavlja omejitve in zahteve, specifične za domeno.
• Uskladitev s poslovnimi cilji :
  • Navsezadnje si prizadeva uskladiti prizadevanja za razvoj programske opreme s strateškimi cilji in cilji podjetja. Z osredotočanjem na razumevanje in modeliranje problemske domene lahko ekipe zagotovijo programske rešitve, ki neposredno podpirajo poslovne cilje, spodbujajo inovacije in ustvarjajo vrednost za deležnike in končne uporabnike.

Izzivi domensko vodenega oblikovanja (DDD)

• Kompleksnost :
  • DDD lahko povzroči kompleksnost, zlasti v velikih in zapletenih domenah.
  • Natančno modeliranje zapletenih poslovnih domen zahteva globoko razumevanje domene in lahko vključuje obravnavanje dvoumnosti in negotovosti. Učinkovito obvladovanje te kompleksnosti zahteva skrbno načrtovanje, sodelovanje in strokovno znanje.
• Vseprisotno prevzemanje jezika :
  • Vzpostavitev in vzdrževanje vseprisotnega jezika – skupnega besedišča, ki natančno predstavlja domenske koncepte – je lahko izziv. Zahteva sodelovanje med razvijalci in strokovnjaki za področje, da prepoznajo izraze in pomene domen in se dogovorijo o njih.
  • Doseganje soglasja o vseprisotnem jeziku bo morda zahtevalo premagovanje komunikacijskih ovir in uskladitev razlik v terminologiji in pogledih.
• Omejena poravnava konteksta :
  • V velikih in kompleksnih domenah imajo lahko različni deli domene različne modele in omejene kontekste. Usklajevanje teh omejenih kontekstov in zagotavljanje skladnosti med njimi je lahko izziv.
  • Zahteva jasno komunikacijo, sodelovanje in usklajevanje med ekipami, ki delajo na različnih delih domene, da bi se izognili nedoslednostim in konfliktom.
• Tehnična zapletenost :
  • Učinkovito izvajanje načel in vzorcev DDD bo morda zahtevalo sprejetje novih tehnologij, okvirov in arhitekturnih pristopov. Integracija DDD z obstoječimi sistemi ali podedovanimi kodnimi bazami je lahko zapletena in lahko zahteva refaktoriranje ali preoblikovanje obstoječe kode za uskladitev z načeli DDD.
  • Tehnične izzive, kot so zmogljivost, razširljivost in vzdržljivost, je treba skrbno obravnavati, da se zagotovi uspeh sprejetja DDD.
• Odpor do sprememb :
  • Uvedba DDD lahko naleti na odpor članov ekipe, ki so navajeni tradicionalnih razvojnih pristopov ali ki menijo, da je DDD preveč zapleten ali nepraktičen.
  • Premagovanje odpora do sprememb zahteva učinkovito komunikacijo, izobraževanje in vodenje, da se pokažejo prednosti DDD in obravnavajo pomisleki in skepticizem.
• Pretirano inženirstvo :
  • Pri uporabi DDD obstaja tveganje prekomernega inženiringa, kjer se ekipe preveč osredotočajo na modeliranje zapletenih domenskih konceptov in uvajajo nepotrebne abstrakcije ali kompleksnost. Najti pravo ravnovesje med preprostostjo in izraznostjo je ključnega pomena, da se izognemo prekomernemu zapletanju oblikovanja in izvedbe.

Primeri uporabe domensko vodenega oblikovanja (DDD)

• Finance in bančništvo :
  • V finančnem sektorju se lahko DDD uporablja za modeliranje kompleksnih finančnih instrumentov, transakcij in regulativnih zahtev. Z natančno predstavitvijo domenskih konceptov, kot so računi, transakcije in portfelji, DDD pomaga zagotoviti celovitost in doslednost finančnih sistemov. Omogoča tudi boljše obvladovanje tveganj, skladnost in poročanje.
• E-trgovina in maloprodaja :
  • Platforme e-trgovine se pogosto ukvarjajo s kompleksnimi domenskimi koncepti, kot so katalogi izdelkov, upravljanje zalog, cene in naročila strank. DDD lahko pomaga pri učinkovitem modeliranju teh konceptov, saj omogoča funkcije, kot so prilagojena priporočila, dinamično oblikovanje cen in poenostavljena obdelava naročil.
• Zdravstveno varstvo in vede o življenju :
  • V zdravstvu se lahko DDD uporablja za modeliranje bolnikovih kartotek, zdravstvenih diagnoz, načrtov zdravljenja in zdravstvenih delovnih tokov. Z natančno predstavitvijo domenskih konceptov, kot so demografija bolnikov, zdravstvene zgodovine in klinični protokoli, DDD omogoča razvoj robustnih sistemov elektronskih zdravstvenih zapisov (EHR), platform za medicinsko slikanje in telemedicinskih aplikacij.
• Zavarovanje :
  • Zavarovalnice upravljajo različne produkte, politike, zahtevke in postopke sklepanja zavarovanj. DDD lahko pomaga pri modeliranju teh zapletenih domenskih konceptov in omogoča funkcije, kot so upravljanje politik, obdelava zahtevkov, ocena tveganja in aktuarska analiza.
• Nepremičnine in upravljanje nepremičnin :
  • Upravljanje nepremičnin in premoženja vključuje obravnavanje različnih nepremičnin, najemov, najemnikov, zahtevkov za vzdrževanje in finančnih transakcij. DDD lahko pomaga pri učinkovitem modeliranju teh domenskih konceptov in omogoča funkcije, kot so seznami nepremičnin, upravljanje najemov, portali za najemnike in sledenje sredstvi.

Realni primer načrtovanja, ki temelji na domeni (DDD)

Izjava o težavi

Recimo, da razvijamo aplikacijo za naročanje prevozov, imenovano RideX. Sistem omogoča uporabnikom, da zahtevajo vožnjo, voznikom, da sprejmejo zahteve za vožnjo, ter olajša koordinacijo voženj med uporabniki in vozniki.

inicializirati seznam python

Vseprisotni jezik

1. Uporabnik : Nanaša se na posameznike, ki zahtevajo vožnjo prek platforme RideX.
2. Voznik : Nanaša se na posameznike, ki uporabnikom zagotavljajo prevoze prek platforme RideX.
3. Zahteva za vožnjo : Predstavlja uporabnikovo zahtevo za prevoz, ki določa podrobnosti, kot so lokacija prevzema, cilj in nastavitve vožnje.
4. Vožnja : Predstavlja en primer vožnje, vključno s podrobnostmi, kot so lokacije prevzema in izstopa, cena vozovnice in trajanje.
5. Stanje vožnje : Predstavlja trenutno stanje vožnje, kot je zahtevano, sprejeto, v teku ali dokončano.

Omejeni konteksti

1. Kontekst upravljanja vožnje : Odgovoren za upravljanje življenjskega cikla voženj, vključno z zahtevami za vožnjo, dodelitvijo vožnje voznikom in posodobitvami statusa vožnje.
2. Kontekst upravljanja uporabnikov : obravnava avtentikacijo uporabnika, registracijo in funkcije, specifične za uporabnika, kot so zgodovina vožnje in načini plačila.
3. Kontekst upravljanja gonilnikov : Upravlja preverjanje pristnosti voznika, registracijo, status razpoložljivosti in funkcije, specifične za voznika, kot so zaslužki in ocene.

Entitete in vrednostni objekti

1. Uporabniška entiteta : Predstavlja registriranega uporabnika platforme RideX z lastnostmi, kot so ID uporabnika, e-pošta, geslo in podatki o plačilu.
2. Entiteta voznika : Predstavlja registriranega voznika na platformi RideX z lastnostmi, kot so ID voznika, podrobnosti o vozilu in status voznika.
3. Subjekt zahteve za vožnjo : Predstavlja uporabnikovo zahtevo za prevoz, vključno z lastnostmi, kot so ID zahteve, prevzemna lokacija, cilj in nastavitve vožnje.
4. Ride Entity : Predstavlja en primerek vožnje, vključno z lastnostmi, kot so ID vožnje, lokacije prevzema in izstopa, cena vozovnice in stanje vožnje.
5. Objekt vrednosti lokacije : Predstavlja geografsko lokacijo z lastnostmi, kot sta zemljepisna širina in dolžina.

Agregati

1. Ride Aggregate : Sestavljen je iz entitete Ride kot zbirnega korena, skupaj s povezanimi entitetami, kot so entitete Ride Request, User in Driver. Ride Aggregate vsebuje logiko za upravljanje življenjskega cikla vožnje, vključno z obravnavanjem zahtev za vožnjo, dodeljevanjem voznikov in posodabljanjem statusa vožnje.

Repozitorij

1. Ride Repository : Zagotavlja metode za poizvedovanje in shranjevanje entitet, povezanih z vožnjo, kot je pridobivanje podrobnosti o vožnji, posodabljanje statusa vožnje in shranjevanje podatkov, povezanih z vožnjo, v zbirko podatkov.

Storitve

1. Storitev dodelitve vožnje : odgovoren za dodeljevanje razpoložljivih voznikov zahtevam za vožnjo na podlagi dejavnikov, kot so razpoložljivost voznika, bližina prevzemne lokacije in uporabniške nastavitve.
2. Plačilna storitev : obravnava obdelavo plačil za opravljene vožnje, izračun vozovnic, obdelavo plačil in posodabljanje podatkov o plačilu uporabnika in voznika.

Dogodki v domeni

1. RideRequestedEvent : Predstavlja dogodek, ki se sproži, ko uporabnik zahteva prevoz, ki vsebuje informacije, kot so podrobnosti zahteve za prevoz in ID uporabnika.
2. RideAcceptedEvent : Predstavlja dogodek, ki se sproži, ko voznik sprejme zahtevo za vožnjo, ki vsebuje informacije, kot so ID vožnje, ID voznika in prevzemna lokacija.

Primer scenarija

1. Uporabnik zahteva prevoz : Uporabnik zahteva prevoz tako, da navede svojo prevzemno lokacijo, cilj in nastavitve vožnje. RideX ustvari novo entiteto zahteve za vožnjo in sproži RideRequestedEvent.
2. Voznik sprejema vožnjo : voznik sprejme zahtevo za vožnjo s platforme RideX. RideX posodobi status vožnje na Sprejeto, dodeli voznika vožnji in sproži RideAcceptedEvent.
3. Vožnja v teku : Uporabnik in voznik usklajujeta vožnjo, pri čemer se status vožnje spremeni iz Sprejeto v V teku, ko voznik doseže lokacijo prevzema.
4. Zaključek vožnje : Ko dosežete cilj, se status vožnje posodobi na Dokončano. RideX izračuna vozovnico, obdela plačilo in ustrezno posodobi podatke o plačilu uporabnika in voznika.