Domain-Driven Design (DDD) – tai programinės įrangos kūrimo metodas, kurio tikslas – suprasti ir modeliuoti probleminę sritį, kurioje veikia programinės įrangos sistema. Jame pabrėžiama, kaip svarbu glaudžiai bendradarbiauti su domeno ekspertais, siekiant giliai suprasti domeno subtilybes ir sudėtingumą. DDD pateikia principų, modelių ir praktikos rinkinį, padedantį kūrėjams efektyviai užfiksuoti ir išreikšti domeno koncepcijas savo programinės įrangos projektuose.

kat timpf svoris

Svarbios domenu pagrįsto dizaino (DDD) temos

• Kas yra domenu pagrįstas dizainas (DDD)?
• Domeno žinių svarba
• Strateginis dizainas domenu pagrįstame projekte (DDD)
• Taktinio dizaino modeliai domenu grindžiamame projekte (DDD)
• Domenu pagrįsto dizaino (DDD) pranašumai
• Domenu grindžiamo dizaino (DDD) iššūkiai
• Domenu pagrįsto dizaino (DDD) naudojimo atvejai
• Realus domenu pagrįsto dizaino (DDD) pavyzdys

Kas yra domenu pagrįstas dizainas (DDD)?

Domenas

Tai reiškia dalykinę sritį arba probleminę sritį, kuriai skirta programinės įrangos sistema. Ji apima realaus pasaulio sąvokas, taisykles ir procesus, kuriuos programinė įranga skirta modeliuoti arba palaikyti. Pavyzdžiui, banko programoje domenas apima tokias sąvokas kaip sąskaitos, operacijos, klientai ir su banko operacijomis susiję reglamentai.

Varomas

Varomas reiškia, kad programinės įrangos sistemos dizainas vadovaujasi arba įtakoja domeno ypatybes ir reikalavimus. Kitaip tariant, projektavimo sprendimai yra pagrįsti giliu srities supratimu, o ne vien tik techniniais sumetimais ar įgyvendinimo detalėmis.

Dizainas

Dizainas reiškia programinės įrangos sistemos plano ar projekto kūrimo procesą. Tai apima sprendimus dėl to, kaip sistema bus struktūrizuota, kaip skirtingi komponentai sąveikaus ir kaip sistema vykdys savo funkcinis ir nefunkcionalus reikalavimus. Domenu pagrįsto dizaino kontekste pagrindinis dėmesys skiriamas programinės įrangos projektavimui taip, kad jis tiksliai atspindėtų domeno struktūrą ir elgesį.

Domenu pagrįstas dizainas yra programuotojo pristatyta koncepcija Erikas Evansas 2004 metais savo knygoje Domenu pagrįstas dizainas: sudėtingumo problemos sprendimas programinės įrangos širdyje

Domeno žinių svarba

Tarkime, kad sukūrėme programinę įrangą naudodami visas naujausias technologijas ir infrastruktūrą, o mūsų programinės įrangos dizaino architektūra yra nuostabi, bet kai išleidžiame šią programinę įrangą į rinką, galiausiai galutinis vartotojas nusprendžia, ar mūsų sistema yra puiki, ar ne. Taip pat jei sistema nesprendžia verslo poreikių, tai ji niekam nenaudinga. Nesvarbu, kaip gražiai jis atrodo ar kokia architektūra yra jo infrastruktūra.

Pagal Erikas Evansas , Kurdami programinę įrangą, pirmiausia turėtume sutelkti dėmesį ne į technologijas, o į verslą. Prisiminti,

Ne kliento darbas žinoti, ko jis nori – Steve'as Jobsas

komanda arp-a

Strateginis dizainas domenu pagrįstame projekte (DDD)

Strateginis projektavimas domenu valdomame projekte (DDD) skirtas apibrėžti bendrą programinės įrangos sistemos architektūrą ir struktūrą taip, kad ji atitiktų problemos sritį. Jame aptariami aukšto lygio klausimai, pavyzdžiui, kaip organizuoti domenų sąvokas, kaip padalinti sistemą į valdomas dalis ir kaip nustatyti aiškias skirtingų komponentų ribas.

Pažvelkime į kai kurias pagrindines strateginio dizaino domenu grindžiamo dizaino (DDD) sąvokas.

1. Apriboti kontekstai

• Apribotas kontekstas reiškia konkrečią bendros problemos srities sritį, kurioje nuosekliai taikomas tam tikras modelis arba kalba.
• Skirtingos sistemos dalys gali turėti skirtingas tų pačių terminų reikšmes, o ribotas kontekstas apibrėžia aiškias ribas, kuriose tie terminai turi konkrečias reikšmes.
• Tai leidžia komandoms kurti modelius, pritaikytus konkrečiam kontekstui, nesukeliant painiavos ar neatitikimų.
• Apriboti kontekstai padeda valdyti sudėtingumą suskaidydami didelį sudėtingą domeną į mažesnes, lengviau valdomas dalis.

2. Konteksto atvaizdavimas

• Konteksto atvaizdavimas yra skirtingų ribotų kontekstų santykių ir sąveikos apibrėžimo procesas.
• Tai apima kontekstų sutapimo arba integracijos sričių nustatymą ir komunikacijos kanalų bei susitarimų tarp jų nustatymą.
• Konteksto atvaizdavimas padeda užtikrinti, kad skirtingos sistemos dalys galėtų veiksmingai bendradarbiauti, išlaikant aiškias ribas tarp jų.
• Yra įvairių konteksto atvaizdavimo modelių ir metodų, tokių kaip partnerystė, bendras branduolys ir klientas-tiekėjas.

3. Strateginiai modeliai

• Strateginiai modeliai yra bendrosios gairės arba principai, kaip organizuoti programinės įrangos sistemos architektūrą taip, kad ji atitiktų problemos sritį.
• Šie modeliai padeda spręsti bendrus iššūkius kuriant sudėtingas sistemas ir pateikia patikrintus metodus, kaip efektyviai struktūrizuoti sistemą.
• Strateginių modelių pavyzdžiai yra agregatai, domeno įvykiai ir kovos su korupcija sluoksnis.
• Šie modeliai pateikia pasikartojančių domeno projektavimo problemų sprendimus ir padeda užtikrinti, kad sistemos architektūra tiksliai atspindėtų pagrindines domeno sąvokas.

4. Bendrinamas branduolys

• Bendras branduolys yra strateginis modelis, apimantis skirtingų apribotų kontekstų bendrumo sferų nustatymą ir bendro domeno modelio poaibio, naudojamo keliuose kontekstuose, sukūrimą.
• Šis bendras poaibis arba branduolys padeda palengvinti bendradarbiavimą ir integravimą tarp kontekstų, kartu leidžiant kiekvienam kontekstui išlaikyti savo atskirą modelį.
• Bendrinamas branduolys turėtų būti naudojamas protingai, nes jis sukuria priklausomybę tarp kontekstų ir gali sukelti susiejimą, jei nebus kruopščiai valdomas.

5. Antikorupcinis sluoksnis (ACL)

• Antikorupcinis sluoksnis yra dar vienas strateginis modelis, padedantis apsaugoti sistemą nuo išorinių arba senų sistemų, naudojančių skirtingus modelius ar kalbas, įtakos.
• ACL veikia kaip vertimo sluoksnis tarp išorinės sistemos ir pagrindinio domeno modelio, prireikus transformuodamas duomenis ir pranešimus, kad būtų užtikrintas suderinamumas.
• Tai leidžia pagrindiniam domeno modeliui išlikti grynam ir sutelktam į probleminę sritį, kartu prireikus integruojantis su išorinėmis sistemomis.

6. Visur paplitusi kalba

Visur vartojama kalba reiškia bendrą žodyną arba kalbą, kuri nuosekliai ir visuotinai naudojama visose suinteresuotose šalyse, kuriant programinę įrangą. Šią kalbą sudaro terminai, frazės ir sąvokos, kurios tiksliai atspindi srities žinias ir sąvokas.

Kai kurie pagrindiniai visur esančios kalbos principai yra šie:

• Bendras supratimas : Pagrindinis „Ubiquitous Language“ tikslas yra sukurti bendrą problemos srities supratimą tarp visų kūrimo komandos narių, įskaitant kūrėjus, domenų ekspertus, verslo analitikus ir suinteresuotąsias šalis. Naudodami bendrą kalbą, visi dalyvaujantys gali efektyviau bendrauti ir tiksliau perteikti srities sąvokas ir reikalavimus.
• Nuoseklumas ir aiškumas : Visur vartojama kalba skatina bendravimo nuoseklumą ir aiškumą, naudodama tikslią ir nedviprasmišką terminiją. Kiekvienas terminas ar frazė kalboje turi turėti aiškią ir sutartą reikšmę,
• Derinimas su verslo koncepcijomis : DDD vartojama kalba turėtų tiksliai atitikti verslo srityje vartojamą terminiją ir sąvokas. Ji turėtų atspindėti, kaip domeno ekspertai galvoja ir kalba apie probleminę sritį, užtikrinant, kad programinė įranga tiksliai atspindėtų realaus pasaulio sąvokas ir procesus.
• Evoliucinė gamta : Visur vartojama kalba nėra statiška, bet laikui bėgant kinta, komandai įgyjant gilesnį domeno supratimą ir keičiantis reikalavimams. Ji turėtų prisitaikyti, kad atspindėtų naujas įžvalgas, atradimus ar verslo prioritetų pokyčius, užtikrinant, kad kalba išliktų aktuali ir atnaujinta viso kūrimo proceso metu.

Taktinio dizaino modeliai domenu grindžiamame projekte (DDD)

Domenu valdomame projekte (DDD) taktiniai projektavimo modeliai yra specifinės strategijos arba metodai, naudojami domeno modeliui struktūrizuoti ir organizuoti programinės įrangos sistemoje. Šie modeliai padeda kūrėjams efektyviai užfiksuoti domeno sudėtingumą, taip pat skatina priežiūrą, lankstumą ir mastelį.

Pažiūrėkime kai kuriuos pagrindinius taktinio dizaino modelius DDD:

1. Esybė

Objektas yra domeno objektas, turintis skirtingą tapatybę ir gyvavimo ciklą. Subjektams būdingi unikalūs identifikatoriai ir kintama būsena. Jie apima elgesį ir duomenis, susijusius su konkrečia sąvoka domene.

Pavyzdžiui, banko programoje aBankAccount>subjektas gali turėti nuosavybės, pvz., sąskaitos numerį, likutį ir savininką, taip pat lėšų įnešimo, išėmimo ar pervedimo būdus.

2. Vertės objektas

Vertės objektas yra domeno objektas, vaizduojantis konceptualiai nekintamą vertę. Skirtingai nuo objektų, vertės objektai neturi atskiros tapatybės ir paprastai naudojami objektų atributams ar savybėms pavaizduoti. Vertybės objektai yra lygūs, palyginti su jų savybėmis, o ne pagal jų tapatybę.

Pavyzdžiui, aMoney>vertės objektas gali atstovauti tam tikrą valiutos sumą, apimančią tokias savybes kaip valiutos tipas ir suma.

3. Suvestinė

• Agregatas yra domeno objektų, kurie duomenų nuoseklumo ir operacijų vientisumo tikslais laikomi vienu vienetu, grupė.
• Agregatai susideda iš vieno ar daugiau objektų ir vertės objektų, o vienas objektas nurodomas kaip suvestinio elemento šaknis.
• Agregato šaknis yra įvesties taškas norint pasiekti ir keisti vidinę agregato būseną.
• Agregatai užtikrina nuoseklumo ribas domeno modelyje ir užtikrina, kad susijusių objektų pakeitimai būtų atliekami atomiškai.

Pavyzdžiui, elektroninės prekybos sistemoje anOrder>agregatą gali sudaryti tokie objektai kaipOrderItem>irCustomer>, suOrder>subjektas, veikiantis kaip suvestinė šaknis.

4. Saugykla

• Saugykla yra mechanizmas, skirtas duomenų prieigos ir patvarumo logikai iš domeno modelio paimti.
• Saugyklose yra standartizuota sąsaja, skirta domeno objektų užklausoms ir saugojimui, slepiant duomenis apie tai, kaip gaunami arba saugomi duomenys. Saugyklos apima vertimo tarp domeno objektų ir pagrindinių duomenų saugojimo mechanizmų, tokių kaip duomenų bazės ar išorinės paslaugos, logiką.
• Atjungus domeno modelį nuo duomenų prieigos problemų, saugyklos suteikia daugiau lankstumo ir priežiūros.

Pavyzdžiui, aCustomerRepository>gali pateikti užklausų ir saugojimo metodusCustomer>subjektai.

5. Gamykla

• Gamykla yra a kūrybos raštas naudojamas sudėtingų domeno objektų egzempliorių kūrimo logikai. Gamyklos abstrahuoja objektų kūrimo procesą, todėl klientai gali kurti objektus nežinant jų konstrukcijos detalių.
• Gamyklos yra ypač naudingos kuriant objektus, kuriems reikalinga sudėtinga inicijavimo logika arba kurie apima kelis veiksmus.

Pavyzdžiui, aProductFactory>gali būti atsakingas už egzempliorių kūrimąProduct>objektų su numatytosiomis konfigūracijomis.

6. Aptarnavimas

• Paslauga yra domeno objektas, vaizduojantis elgseną arba operaciją, kuri natūraliai nepriklauso jokiam konkrečiam objektui ar vertės objektui.
• Paslaugos apima domeno logiką, kuri veikia keliuose objektuose arba organizuoja sąveiką tarp objektų.
• Paslaugos paprastai yra be būsenos ir yra skirtos konkrečioms užduotims atlikti arba domeno taisyklių vykdymui.

Pavyzdžiui, anOrderService>gali pateikti užsakymų apdorojimo, nuolaidų taikymo ir pristatymo išlaidų apskaičiavimo metodus.

Domenu pagrįsto dizaino (DDD) pranašumai

• Bendras supratimas :
  • Tai skatina bendradarbiavimą tarp domenų ekspertų, kūrėjų ir suinteresuotųjų šalių.
  • Skatindamos bendrą problemos srities supratimą visur esančia kalba, komandos gali efektyviau bendrauti ir užtikrinti, kad programinė įranga tiksliai atspindėtų verslo poreikius ir reikalavimus.
• Sutelkite dėmesį į pagrindinį domeną :
  • Tai padeda komandoms nustatyti pagrindinę programos domeną ir teikti pirmenybę sistemos sritims, kurios teikia didžiausią vertę verslui. Sutelkdamos kūrimo pastangas į pagrindinį domeną, komandos gali teikti funkcijas, kurios tiesiogiai atitinka verslo tikslus ir išskiria programinę įrangą nuo konkurentų.
• Atsparumas pokyčiams :
  • Jame akcentuojamas programinės įrangos sistemų, atsparių pokyčiams, projektavimas, modeliuojant domeną taip, kad būtų atspindėtas problemos srities sudėtingumas ir neapibrėžtumas.
  • Priimdamos pokyčius kaip natūralią programinės įrangos kūrimo dalį, komandos gali efektyviau reaguoti į besikeičiančius verslo poreikius ir rinkos sąlygas.
• Aiškus rūpesčių atskyrimas :
  • DDD skatina aiškiai atskirti domeno logikos, infrastruktūros ir vartotojo sąsajos problemas. Atskirdamos domeno logiką nuo techninių detalių ir infrastruktūros problemų, komandos gali išlaikyti švarų ir kryptingą domeno modelį, kuris nepriklauso nuo konkrečių diegimo detalių ar technologinių pasirinkimų.
• Patobulintas tikrinamumas :
  • Tai skatina naudoti domeno objektus su tiksliai apibrėžtomis ribomis ir elgesiu, todėl lengviau rašyti geresnius ir tikslesnius testus, patvirtinančius domeno logikos teisingumą.
  • Kurdamos programinės įrangos sistemas atsižvelgdamos į testavimo galimybes, komandos gali užtikrinti, kad kodų bazės pakeitimai būtų saugūs ir nuspėjami, taip sumažinant regresijos ar nenumatytų šalutinių poveikių riziką.
• Sudėtingų verslo taisyklių palaikymas :
  • Jame pateikiami modeliai ir metodai, skirti modeliuoti ir įgyvendinti sudėtingas verslo taisykles ir darbo eigas domeno modelyje.
  • Aiškiai pateikdamos verslo taisykles domeno modelyje, komandos gali užtikrinti, kad programinė įranga tiksliai atspindėtų verslo srities sudėtingumą ir įgyvendintų konkrečiam domenui taikomus apribojimus ir reikalavimus.
• Derinimas su verslo tikslais :
  • Galiausiai juo siekiama suderinti programinės įrangos kūrimo pastangas su strateginiais verslo tikslais ir uždaviniais. Sutelkdamos dėmesį į problemos srities supratimą ir modeliavimą, komandos gali pateikti programinės įrangos sprendimus, kurie tiesiogiai palaiko verslo tikslus, skatina naujoves ir kuria vertę suinteresuotosioms šalims ir galutiniams vartotojams.

Domenu grindžiamo dizaino (DDD) iššūkiai

• Sudėtingumas :
  • DDD gali sukelti sudėtingumą, ypač didelėse ir sudėtingose ​​srityse.
  • Norint tiksliai modeliuoti sudėtingas verslo sritis, reikalingas gilus šios srities supratimas ir gali reikėti spręsti dviprasmybes ir netikrumą. Norint veiksmingai valdyti šį sudėtingumą, reikia kruopštaus planavimo, bendradarbiavimo ir patirties.
• Visur paplitusios kalbos priėmimas :
  • Sukurti ir palaikyti visur paplitusią kalbą – bendrą žodyną, kuris tiksliai atspindi srities sąvokas – gali būti sudėtinga. Norint nustatyti ir susitarti dėl domeno terminų ir reikšmių, reikia bendradarbiauti kūrėjai ir domeno ekspertai.
  • Norint pasiekti sutarimą dėl visur paplitusios kalbos, gali prireikti įveikti bendravimo kliūtis ir suderinti terminijos bei perspektyvų skirtumus.
• Apribotas konteksto lygiavimas :
  • Didelėse ir sudėtingose ​​srityse skirtingos domeno dalys gali turėti skirtingus modelius ir ribotą kontekstą. Suderinti šiuos ribotus kontekstus ir užtikrinti jų nuoseklumą gali būti sudėtinga.
  • Tam reikia aiškaus bendravimo, bendradarbiavimo ir koordinavimo tarp komandų, dirbančių skirtingose ​​domeno dalyse, kad būtų išvengta neatitikimų ir konfliktų.
• Techninis sudėtingumas :
  • Norint veiksmingai įgyvendinti DDD principus ir modelius, gali prireikti taikyti naujas technologijas, sistemas ir architektūrinius metodus. DDD integravimas su esamomis sistemomis ar senomis kodų bazėmis gali būti sudėtingas ir gali tekti pertvarkyti arba perdaryti esamą kodą, kad jis atitiktų DDD principus.
  • Techniniai iššūkiai, tokie kaip našumas, mastelio keitimas ir priežiūra, turi būti kruopščiai sprendžiami siekiant užtikrinti sėkmingą DDD diegimą.
• Atsparumas pokyčiams :
  • Pristatant DDD gali susidurti su pasipriešinimu iš komandos narių, kurie yra pripratę prie tradicinių plėtros metodų arba kurie mano, kad DDD yra pernelyg sudėtingas ar nepraktiškas.
  • Norint įveikti pasipriešinimą pokyčiams, reikia veiksmingo bendravimo, išsilavinimo ir vadovavimo, kad būtų parodyta DDD nauda ir išspręstų susirūpinimą bei skepticizmą.
• Perdėta inžinerija :
  • Taikant DDD kyla pernelyg didelės inžinerijos rizika, kai komandos per daug dėmesio skiria sudėtingų domenų koncepcijų modeliavimui ir nereikalingų abstrakcijų ar sudėtingumo įvedimui. Norint, kad dizainas ir įgyvendinimas nebūtų pernelyg sudėtingas, labai svarbu rasti tinkamą pusiausvyrą tarp paprastumo ir išraiškingumo.

Domenu pagrįsto dizaino (DDD) naudojimo atvejai

• Finansai ir bankininkystė :
  • Finansų sektoriuje DDD gali būti naudojamas sudėtingoms finansinėms priemonėms, sandoriams ir reguliavimo reikalavimams modeliuoti. Tiksliai pateikdamas domeno sąvokas, tokias kaip sąskaitos, operacijos ir portfeliai, DDD padeda užtikrinti finansų sistemų vientisumą ir nuoseklumą. Tai taip pat leidžia geriau valdyti riziką, užtikrinti atitiktį ir ataskaitų teikimą.
• Elektroninė prekyba ir mažmeninė prekyba :
  • El. prekybos platformos dažnai susiduria su sudėtingomis domeno sąvokomis, tokiomis kaip produktų katalogai, atsargų valdymas, kainodara ir klientų užsakymai. DDD gali padėti efektyviai modeliuoti šias koncepcijas, įgalindamas tokias funkcijas kaip suasmenintos rekomendacijos, dinamiška kainodara ir supaprastintas užsakymų apdorojimas.
• Sveikatos priežiūra ir gyvosios gamtos mokslai :
  • Sveikatos priežiūros srityje DDD gali būti naudojamas pacientų įrašams, medicininėms diagnozėms, gydymo planams ir sveikatos priežiūros darbo eigoms modeliuoti. Tiksliai pateikdamas domeno sąvokas, tokias kaip pacientų demografija, ligos istorijos ir klinikiniai protokolai, DDD leidžia kurti patikimas elektroninių sveikatos įrašų (EHR) sistemas, medicininio vaizdo platformas ir telemedicinos programas.
• Draudimas :
  • Draudimo bendrovės valdo įvairius produktus, politiką, pretenzijas ir draudimo procesus. DDD gali padėti modeliuoti šias sudėtingas domeno sąvokas, įgalindamas tokias funkcijas kaip politikos valdymas, pretenzijų apdorojimas, rizikos vertinimas ir aktuarinė analizė.
• Nekilnojamojo turto ir turto valdymas :
  • Nekilnojamasis turtas ir turto valdymas apima įvairaus turto, nuomos, nuomininkų, priežiūros prašymų ir finansinių operacijų tvarkymą. DDD gali padėti efektyviai modeliuoti šias domeno koncepcijas, įgalindamas tokias funkcijas kaip nekilnojamojo turto sąrašai, nuomos valdymas, nuomininkų portalai ir turto stebėjimas.

Realus domenu pagrįsto dizaino (DDD) pavyzdys

Problemos pareiškimas

Tarkime, kuriame pavėžėjimo programą, pavadintą RideX. Sistema leidžia vartotojams prašyti važiuoti, vairuotojams priimti važiavimo užklausas ir palengvina važiavimo koordinavimą tarp naudotojų ir vairuotojų.

Java pavyzdinis kodas

Visur paplitusi kalba

1. Vartotojas : nurodo asmenis, kurie prašo važiuoti per RideX platformą.
2. Vairuotojas : nurodo asmenis, kurie teikia pavėžėjimą naudotojams per RideX platformą.
3. Prašymas važiuoti : reiškia naudotojo užklausą važiuoti, nurodant tokią informaciją kaip paėmimo vieta, kelionės tikslas ir važiavimo nuostatos.
4. Važiuoti : reiškia vieną kelionės atvejį, įskaitant informaciją, pvz., paėmimo ir išlaipinimo vietas, bilieto kainą ir trukmę.
5. Važiavimo būsena : rodo dabartinę važiavimo būseną, pvz., Užklausta, Priimta, Vykdoma arba Užbaigta.

Apriboti kontekstai

1. Važiavimo valdymo kontekstas : atsakingas už važiavimo ciklo valdymą, įskaitant važiavimo užklausas, važiavimo paskyrimus vairuotojams ir važiavimo būsenos atnaujinimus.
2. Vartotojo valdymo kontekstas : tvarko vartotojo autentifikavimą, registraciją ir konkrečias vartotojo funkcijas, pvz., važiavimo istoriją ir mokėjimo metodus.
3. Vairuotojo valdymo kontekstas : tvarko vairuotojo autentifikavimą, registraciją, pasiekiamumo būseną ir vairuotojui būdingas funkcijas, pvz., uždarbį ir įvertinimus.

Esybės ir vertybiniai objektai

1. Vartotojo subjektas : atstovauja registruotam RideX platformos vartotojui su tokiomis savybėmis kaip vartotojo ID, el. paštas, slaptažodis ir mokėjimo informacija.
2. Vairuotojo subjektas : reiškia registruotą vairuotoją RideX platformoje su tokiomis savybėmis kaip vairuotojo ID, transporto priemonės informacija ir vairuotojo būsena.
3. Važiavimo užklausos subjektas : reiškia naudotojo užklausą važiuoti, įskaitant ypatybes, pvz., užklausos ID, paėmimo vietą, tikslą ir važiavimo nuostatas.
4. Važiavimo subjektas : reiškia vieną kelionės atvejį, įskaitant tokias savybes kaip kelionės ID, paėmimo ir išlaipinimo vietos, bilieto kaina ir kelionės būsena.
5. Vietos vertės objektas : reiškia geografinę vietą su tokiomis savybėmis kaip platuma ir ilguma.

Agregatai

1. Važiavimo agregatas : susideda iš važiavimo objekto kaip bendros šaknies ir susijusių objektų, tokių kaip važiavimo užklausa, naudotojas ir vairuotojas. „Ride Aggregate“ apima važiavimo gyvavimo ciklo valdymo logiką, įskaitant važiavimo užklausų tvarkymą, vairuotojų priskyrimą ir važiavimo būsenos atnaujinimą.

Saugykla

1. Ride saugykla : pateikia užklausų ir su važiavimu susijusių objektų saugojimo metodus, pvz., kelionės informacijos gavimą, važiavimo būsenos atnaujinimą ir su važiavimu susijusių duomenų saugojimą duomenų bazėje.

Paslaugos

1. Važiavimo paskyrimo paslauga : atsakingas už turimų vairuotojų priskyrimą važiavimo užklausoms, atsižvelgiant į tokius veiksnius kaip vairuotojo pasiekiamumas, atstumas iki paėmimo vietos ir naudotojo nuostatos.
2. Mokėjimo paslauga : tvarko mokėjimų už užbaigtus važiavimus apdorojimą, bilietų kainų apskaičiavimą, mokėjimų apdorojimą ir naudotojo bei vairuotojo mokėjimo informacijos atnaujinimą.

Domeno įvykiai

1. RideRequestedEvent : reiškia įvykį, suaktyvintą, kai vartotojas paprašo važiuoti, ir apima informaciją, pvz., išsamią pavėžėjimo užklausos informaciją ir vartotojo ID.
2. RideAcceptedEvent : reiškia įvykį, suaktyvintą, kai vairuotojas priima važiavimo užklausą, kurioje pateikiama tokia informacija kaip važiavimo ID, vairuotojo ID ir paėmimo vieta.

Scenarijaus pavyzdys

1. Naudotojas, norintis važiuoti : vartotojas prašo pavežti nurodydamas savo paėmimo vietą, tikslą ir važiavimo nuostatas. „RideX“ sukuria naują važiavimo užklausos objektą ir suaktyvina „RideRequestedEvent“.
2. Vairuotojas, priimantis važiavimą : Vairuotojas priima važiavimo užklausą iš RideX platformos. „RideX“ atnaujina važiavimo būseną į „Accepted“, priskiria vairuotojui važiavimui ir suaktyvina „RideAcceptedEvent“.
3. Vyksta važiavimas : naudotojas ir vairuotojas koordinuoja važiavimą, o važiavimo būsena pereina iš Priimta į Vykdoma, kai vairuotojas pasiekia paėmimo vietą.
4. Važiavimo užbaigimas : Pasiekus tikslą, važiavimo būsena atnaujinama į Baigta. „RideX“ apskaičiuoja bilieto kainą, apdoroja mokėjimą ir atitinkamai atnaujina vartotojo ir vairuotojo mokėjimo informaciją.