Domain-Driven Design (DDD) ir programmatūras izstrādes pieeja, kas koncentrējas uz problēmas jomas, kurā darbojas programmatūras sistēma, izpratni un modelēšanu. Tajā uzsvērts, cik svarīgi ir cieši sadarboties ar domēna ekspertiem, lai attīstītu dziļu izpratni par domēna sarežģītību un sarežģītību. DDD nodrošina principu, modeļu un prakses kopumu, lai palīdzētu izstrādātājiem efektīvi uztvert un izteikt domēna koncepcijas savos programmatūras projektos.

hrithik roshan

Svarīgas tēmas domēnu vadītam dizainam (DDD)

• Kas ir domēna vadīts dizains (DDD)?
• Domēna zināšanu nozīme
• Stratēģiskais dizains domēnu vadītā dizainā (DDD)
• Taktiskā dizaina modeļi domēnu vadītā dizainā (DDD)
• Domēnu vadīta dizaina (DDD) priekšrocības
• Domēnu virzīta dizaina (DDD) izaicinājumi
• Domēna virzīta dizaina (DDD) lietošanas gadījumi
• Reāls domēnu vadīta dizaina (DDD) piemērs

Kas ir domēna vadīts dizains (DDD)?

Domēns

Tas attiecas uz tematu vai problēmu jomu, kuras risināšanai tiek veidota programmatūras sistēma. Tas ietver reālās pasaules koncepcijas, noteikumus un procesus, kurus programmatūra ir paredzēta modelēšanai vai atbalstam. Piemēram, bankas lietojumprogrammā domēns ietver tādus jēdzienus kā konti, darījumi, klienti un noteikumi, kas saistīti ar banku operācijām.

Braukts

Driven nozīmē, ka programmatūras sistēmas dizains tiek vadīts vai ietekmēts no domēna īpašībām un prasībām. Citiem vārdiem sakot, dizaina lēmumu pamatā ir dziļa jomas izpratne, nevis tikai tehniski apsvērumi vai ieviešanas detaļas.

Dizains

Dizains attiecas uz programmatūras sistēmas plāna vai projekta izveides procesu. Tas ietver lēmumus par to, kā sistēma tiks strukturēta, kā dažādi komponenti mijiedarbosies un kā sistēma izpildīs savu funkcionāls un nefunkcionāls prasībām. Domēna virzīta dizaina kontekstā galvenā uzmanība tiek pievērsta programmatūras izstrādei tā, lai tā precīzi atspoguļotu domēna struktūru un uzvedību.

Ar domēnu orientēts dizains ir programmētāja ieviests jēdziens Ēriks Evanss 2004. gadā savā grāmatā Uz domēnu orientēts dizains: programmatūras centrā esošās sarežģītības novēršana

Domēna zināšanu nozīme

Pieņemsim, ka esam izstrādājuši programmatūru, izmantojot visu jaunāko tehnoloģiju kopumu un infrastruktūru, un mūsu programmatūras dizaina arhitektūra ir pārsteidzoša, taču, kad mēs izlaižam šo programmatūru tirgū, galu galā galalietotājs izlemj, vai mūsu sistēma ir lieliska vai nē. Arī tad, ja sistēma nerisina biznesa vajadzības, tad tā nevienam neder. Neatkarīgi no tā, cik skaisti tas izskatās vai cik laba ir tās infrastruktūras arhitektūra.

Saskaņā ar Ēriks Evanss , Izstrādājot programmatūru, mūsu uzmanības centrā nevajadzētu būt galvenokārt tehnoloģijām, bet gan galvenokārt biznesam. Atcerieties,

Klienta pienākums nav zināt, ko viņš vēlas – Stīvs Džobss

Stratēģiskais dizains domēnu vadītā dizainā (DDD)

Stratēģiskais dizains domēnu vadītā dizainā (DDD) koncentrējas uz programmatūras sistēmas vispārējās arhitektūras un struktūras definēšanu tādā veidā, kas atbilst problēmas jomai. Tas pievēršas augsta līmeņa problēmām, piemēram, kā organizēt domēna koncepcijas, kā sadalīt sistēmu pārvaldāmās daļās un kā noteikt skaidras robežas starp dažādiem komponentiem.

Apskatīsim dažus galvenos jēdzienus stratēģiskā dizaina jomā domēnu vadītā dizainā (DDD).

1. Ierobežotie konteksti

• Ierobežotais konteksts apzīmē noteiktu jomu kopējā problēmas jomā, kurā konsekventi tiek piemērots konkrēts modelis vai valoda.
• Dažādām sistēmas daļām vieniem un tiem pašiem terminiem var būt atšķirīga nozīme, un ierobežotais konteksts nosaka skaidras robežas, kurās šiem terminiem ir īpaša nozīme.
• Tas ļauj komandām izstrādāt modeļus, kas ir pielāgoti konkrētam kontekstam, neradot neskaidrības vai neatbilstības.
• Ierobežoti konteksti palīdz pārvaldīt sarežģītību, sadalot lielu, sarežģītu domēnu mazākās, vieglāk pārvaldāmās daļās.

2. Konteksta kartēšana

• Konteksta kartēšana ir dažādu ierobežoto kontekstu attiecību un mijiedarbības noteikšanas process.
• Tas ietver kontekstu pārklāšanās vai integrācijas jomu noteikšanu un saziņas kanālu un līgumu izveidi starp tiem.
• Konteksta kartēšana palīdz nodrošināt, ka dažādas sistēmas daļas var efektīvi sadarboties, vienlaikus saglabājot skaidras robežas starp tām.
• Konteksta kartēšanai ir dažādi modeļi un metodes, piemēram, partnerība, kopīgs kodols un klients-piegādātājs.

3. Stratēģiskie modeļi

• Stratēģiskie modeļi ir vispārīgas vadlīnijas vai principi programmatūras sistēmas arhitektūras organizēšanai tā, lai tā atbilstu problēmas jomai.
• Šie modeļi palīdz risināt kopējās problēmas sarežģītu sistēmu projektēšanā un nodrošina pārbaudītas pieejas sistēmas efektīvai strukturēšanai.
• Stratēģisko modeļu piemēri ir apkopojumi, domēna notikumi un pretkorupcijas slānis.
• Šie modeļi sniedz risinājumus atkārtotām problēmām domēnu vadītā dizainā un palīdz nodrošināt, ka sistēmas arhitektūra precīzi atspoguļo pamatā esošās domēna koncepcijas.

4. Koplietots kodols

• Koplietotais kodols ir stratēģisks modelis, kas ietver kopīgu jomu noteikšanu starp dažādiem ierobežotiem kontekstiem un kopīgas domēna modeļa apakškopas izveidi, ko izmanto vairāki konteksti.
• Šī koplietotā apakškopa jeb kodols palīdz atvieglot sadarbību un integrāciju starp kontekstiem, vienlaikus ļaujot katram kontekstam saglabāt savu atšķirīgo modeli.
• Koplietotais kodols ir jāizmanto saprātīgi, jo tas rada atkarību starp kontekstiem un var izraisīt savienojumu, ja tas netiek rūpīgi pārvaldīts.

5. Pretkorupcijas slānis (ACL)

• Pretkorupcijas slānis ir vēl viens stratēģisks modelis, kas palīdz aizsargāt sistēmu no ārējo vai mantoto sistēmu ietekmes, kas izmanto dažādus modeļus vai valodas.
• ACL darbojas kā tulkošanas slānis starp ārējo sistēmu un galvenā domēna modeli, pārveidojot datus un ziņojumus pēc vajadzības, lai nodrošinātu saderību.
• Tas ļauj galvenā domēna modelim palikt tīram un koncentrētam uz problēmas jomu, vienlaikus integrējoties ar ārējām sistēmām, ja nepieciešams.

6. Visuresošā valoda

Visuresošā valoda attiecas uz kopīgu vārdu krājumu vai valodu, ko konsekventi un universāli lieto visas programmatūras sistēmas izstrādē iesaistītās puses. Šī valoda sastāv no terminiem, frāzēm un jēdzieniem, kas precīzi atspoguļo domēna zināšanas un jēdzienus.

alfabēta cipari

Daži no galvenajiem visuresošās valodas principiem ir:

• Kopīga izpratne : Ubiquitous Language galvenais mērķis ir izveidot kopīgu izpratni par problēmu jomu starp visiem izstrādes komandas locekļiem, tostarp izstrādātājiem, domēna ekspertiem, biznesa analītiķiem un ieinteresētajām personām. Izmantojot kopīgu valodu, visi iesaistītie var efektīvāk sazināties un precīzāk nodot domēna koncepcijas un prasības.
• Konsekvence un skaidrība : visuresošā valoda veicina konsekvenci un skaidrību saziņā, izmantojot precīzu un nepārprotamu terminoloģiju. Katram terminam vai frāzei valodā ir jābūt skaidrai un saskaņotai nozīmei,
• Saskaņošana ar biznesa koncepcijām : DDD izmantotajai valodai ir cieši jāatbilst terminoloģijai un jēdzieniem, ko izmanto uzņēmējdarbības jomā. Tam ir jāatspoguļo veids, kā domēna eksperti domā un runā par problēmu jomu, nodrošinot, ka programmatūra precīzi atspoguļo reālās pasaules koncepcijas un procesus.
• Evolūcijas daba : visuresošā valoda nav statiska, bet laika gaitā attīstās, jo komanda iegūst dziļāku izpratni par domēnu un mainās prasības. Tai ir jāpielāgojas, lai atspoguļotu jaunas atziņas, atklājumus vai izmaiņas biznesa prioritātēs, nodrošinot, ka valoda paliek atbilstoša un aktuāla visā izstrādes procesā.

Taktiskā dizaina modeļi domēnu vadītā dizainā (DDD)

Domēna vadītajā projektēšanā (DDD) taktiskās izstrādes modeļi ir īpašas stratēģijas vai metodes, ko izmanto, lai strukturētu un organizētu domēna modeli programmatūras sistēmā. Šie modeļi palīdz izstrādātājiem efektīvi uztvert domēna sarežģītību, vienlaikus veicinot apkopi, elastību un mērogojamību.

Ļaujiet mums redzēt dažus no galvenajiem taktiskā dizaina modeļiem DDD:

1. Entītija

Entītija ir domēna objekts, kam ir atšķirīga identitāte un dzīves cikls. Entītijas raksturo to unikālie identifikatori un mainīgs stāvoklis. Tie ietver uzvedību un datus, kas saistīti ar konkrētu jēdzienu domēnā.

Piemēram, bankas lietojumprogrammā aBankAccount>entītijai var būt tādi rekvizīti kā konta numurs, atlikums un īpašnieks, kā arī līdzekļu noguldīšanas, izņemšanas vai pārskaitīšanas metodes.

2. Vērtības objekts

Vērtības objekts ir domēna objekts, kas pārstāv konceptuāli nemainīgu vērtību. Atšķirībā no entītijām, vērtību objektiem nav noteiktas identitātes, un tos parasti izmanto, lai attēlotu entītiju atribūtus vai īpašības. Vērtību objekti ir vienlīdzīgi salīdzināmi, pamatojoties uz to īpašībām, nevis to identitāti.

Piemēram, aMoney>vērtības objekts var attēlot noteiktu valūtas daudzumu, iekapsulējot tādas īpašības kā valūtas veids un summa.

3. Agregāts

• Apkopojums ir domēna objektu kopa, kas datu konsekvences un darījumu integritātes nolūkos tiek uzskatīta par vienu vienību.
• Apkopojumi sastāv no vienas vai vairākām entītijām un vērtību objektiem, un viena entītija ir norādīta kā apkopojuma sakne.
• Agregāta sakne kalpo kā ieejas punkts, lai piekļūtu apkopojuma iekšējam stāvoklim un mainītu to.
• Agregāti ievieš konsekvences robežas domēna modelī, nodrošinot, ka izmaiņas saistītajos objektos tiek veiktas atomiski.

Piemēram, e-komercijas sistēmā anOrder>agregāts var sastāvēt no tādām entītijām kāOrderItem>unCustomer>, ArOrder>entītija, kas kalpo kā apkopotā sakne.

4. Repozitorijs

• Repozitorijs ir mehānisms datu piekļuves un noturības loģikas abstrahēšanai no domēna modeļa.
• Repozitoriji nodrošina standartizētu interfeisu domēna objektu vaicāšanai un glabāšanai, slēpjot informāciju par to, kā dati tiek izgūti vai glabāti. Krātuves ietver loģiku tulkošanai starp domēna objektiem un pamatā esošajiem datu uzglabāšanas mehānismiem, piemēram, datu bāzēm vai ārējiem pakalpojumiem.
• Atdalot domēna modeli no datu piekļuves problēmām, repozitoriji nodrošina lielāku elastību un apkopi.

Piemēram, aCustomerRepository>var nodrošināt vaicājumu un glabāšanas metodesCustomer>entītijām.

5. Rūpnīca

• Rūpnīca ir a radīšanas modelis izmanto, lai iekapsulētu loģiku, lai izveidotu sarežģītu domēna objektu gadījumus. Rūpnīcas abstrahē objektu inscenēšanas procesu, ļaujot klientiem izveidot objektus, nezinot to konstrukcijas detaļas.
• Rūpnīcas ir īpaši noderīgas, lai izveidotu objektus, kuriem nepieciešama sarežģīta inicializācijas loģika vai kas ietver vairākas darbības.

Piemēram, aProductFactory>var būt atbildīgs par gadījumu izveidiProduct>entītijas ar noklusējuma konfigurācijām.

6. Serviss

• Pakalpojums ir domēna objekts, kas attēlo uzvedību vai darbību, kas dabiski nepieder nevienai konkrētai entītijai vai vērtības objektam.
• Pakalpojumi iekapsulē domēna loģiku, kas darbojas ar vairākiem objektiem vai organizē mijiedarbību starp objektiem.
• Pakalpojumi parasti ir bezvalstnieki un koncentrējas uz konkrētu uzdevumu veikšanu vai domēna noteikumu izpildi.

Piemēram, anOrderService>var nodrošināt metodes pasūtījumu apstrādei, atlaižu piemērošanai un piegādes izmaksu aprēķināšanai.

Domēnu vadīta dizaina (DDD) priekšrocības

• Kopīga izpratne :
  • Tas veicina sadarbību starp domēna ekspertiem, izstrādātājiem un ieinteresētajām personām.
  • Veicinot kopīgu izpratni par problēmu jomu, izmantojot visuresošo valodu, komandas var efektīvāk sazināties un nodrošināt, ka programmatūra precīzi atspoguļo uzņēmuma vajadzības un prasības.
• Koncentrējieties uz galveno domēnu :
  • Tas palīdz komandām identificēt un noteikt prioritātes lietojumprogrammas galvenajam domēnam — tās sistēmas jomas, kas nodrošina vislielāko vērtību uzņēmumam. Koncentrējot attīstības centienus uz galveno domēnu, komandas var nodrošināt funkcionalitāti, kas tieši atbilst biznesa mērķiem un atšķir programmatūru no konkurentiem.
• Izturība pret pārmaiņām :
  • Tas uzsver programmatūras sistēmu projektēšanu, kas ir noturīgas pret izmaiņām, modelējot domēnu tā, lai atspoguļotu problēmas jomas raksturīgo sarežģītību un nenoteiktību.
  • Pieņemot pārmaiņas kā dabisku programmatūras izstrādes sastāvdaļu, komandas var efektīvāk reaģēt uz mainīgajām biznesa vajadzībām un tirgus apstākļiem.
• Skaidra rūpju nošķiršana :
  • DDD mudina skaidri nodalīt problēmas starp domēna loģiku, infrastruktūru un lietotāja interfeisu. Izolējot domēna loģiku no tehniskām detaļām un infrastruktūras problēmām, komandas var uzturēt tīru un koncentrētu domēna modeli, kas nav atkarīgs no konkrētām ieviešanas detaļām vai tehnoloģiskām izvēlēm.
• Uzlabota pārbaudāmība :
  • Tas veicina domēna objektu izmantošanu ar labi definētām robežām un uzvedību, atvieglojot labāku un mērķtiecīgāku testu rakstīšanu, kas pārbauda domēna loģikas pareizību.
  • Izstrādājot programmatūras sistēmas, paturot prātā pārbaudāmību, komandas var nodrošināt, ka izmaiņas kodu bāzē ir drošas un paredzamas, samazinot regresijas vai neparedzētu blakusparādību risku.
• Sarežģītu uzņēmējdarbības noteikumu atbalsts :
  • Tas nodrošina modeļus un metodes sarežģītu biznesa noteikumu un darbplūsmu modelēšanai un ieviešanai domēna modelī.
  • Domēna modelī skaidri attēlojot biznesa noteikumus, komandas var nodrošināt, ka programmatūra precīzi atspoguļo biznesa domēna sarežģītību un ievieš domēnam raksturīgus ierobežojumus un prasības.
• Saskaņošana ar biznesa mērķiem :
  • Galu galā tā mērķis ir saskaņot programmatūras izstrādes centienus ar uzņēmuma stratēģiskajiem mērķiem un uzdevumiem. Koncentrējoties uz problēmas jomas izpratni un modelēšanu, komandas var nodrošināt programmatūras risinājumus, kas tieši atbalsta biznesa mērķus, virza inovācijas un rada vērtību ieinteresētajām personām un galalietotājiem.

Domēnu virzīta dizaina (DDD) izaicinājumi

• Sarežģītība :
  • DDD var radīt sarežģītību, īpaši lielos un sarežģītos domēnos.
  • Sarežģītu uzņēmējdarbības jomu precīzai modelēšanai ir nepieciešama dziļa izpratne par šo jomu, un tas var ietvert neskaidrības un nenoteiktību. Šīs sarežģītības efektīvai pārvaldībai nepieciešama rūpīga plānošana, sadarbība un zināšanas.
• visuresoša valodas pieņemšana :
  • Izveidot un uzturēt visuresošu valodu — kopīgu vārdu krājumu, kas precīzi atspoguļo domēna jēdzienus — var būt izaicinājums. Tas prasa sadarbību starp izstrādātājiem un domēna ekspertiem, lai noteiktu un vienotos par domēna terminiem un nozīmi.
  • Lai panāktu vienprātību par visuresošo valodu, var būt jāpārvar saziņas barjeras un jāsaskaņo atšķirības terminoloģijā un perspektīvās.
• Ierobežota konteksta līdzināšana :
  • Lielos un sarežģītos domēnos dažādām domēna daļām var būt atšķirīgi modeļi un ierobežots konteksts. Šo ierobežoto kontekstu saskaņošana un konsekvences nodrošināšana starp tiem var būt izaicinājums.
  • Tam nepieciešama skaidra komunikācija, sadarbība un koordinācija starp komandām, kas strādā dažādās domēna daļās, lai izvairītos no neatbilstībām un konfliktiem.
• Tehniskā sarežģītība :
  • Lai efektīvi ieviestu DDD principus un modeļus, var būt nepieciešams pieņemt jaunas tehnoloģijas, ietvarus un arhitektūras pieejas. DDD integrēšana ar esošajām sistēmām vai mantotajām kodu bāzēm var būt sarežģīta, un var būt nepieciešams pārveidot vai pārveidot esošo kodu, lai tas atbilstu DDD principiem.
  • Lai nodrošinātu veiksmīgu DDD pieņemšanu, rūpīgi jārisina tādi tehniski izaicinājumi kā veiktspēja, mērogojamība un apkope.
• Izturība pret pārmaiņām :
  • Ieviešot DDD, var rasties pretestība no komandas locekļu puses, kuri ir pieraduši pie tradicionālām attīstības pieejām vai uztver DDD kā pārāk sarežģītu vai nepraktisku.
  • Lai pārvarētu pretestību pārmaiņām, ir nepieciešama efektīva komunikācija, izglītošana un vadība, lai parādītu DDD priekšrocības un novērstu bažas un skepsi.
• Pārmērīga inženierija :
  • Lietojot DDD, pastāv pārmērīgas inženierijas risks, kad komandas pārāk daudz koncentrējas uz sarežģītu domēna koncepciju modelēšanu un nevajadzīgu abstrakciju vai sarežģītības ieviešanu. Lai izvairītos no dizaina un ieviešanas pārmērīgas sarežģītības, ir ļoti svarīgi atrast pareizo līdzsvaru starp vienkāršību un izteiksmīgumu.

Domēna virzīta dizaina (DDD) lietošanas gadījumi

• Finanses un banku darbība :
  • Finanšu sektorā DDD var izmantot sarežģītu finanšu instrumentu, darījumu un normatīvo prasību modelēšanai. Precīzi attēlojot domēna jēdzienus, piemēram, kontus, darījumus un portfeļus, DDD palīdz nodrošināt finanšu sistēmu integritāti un konsekvenci. Tas arī nodrošina labāku riska pārvaldību, atbilstību un ziņošanu.
• E-komercija un mazumtirdzniecība :
  • E-komercijas platformas bieži nodarbojas ar sarežģītiem domēna jēdzieniem, piemēram, produktu katalogiem, krājumu pārvaldību, cenu noteikšanu un klientu pasūtījumiem. DDD var palīdzēt efektīvi modelēt šīs koncepcijas, nodrošinot tādas funkcijas kā personalizēti ieteikumi, dinamiska cenu noteikšana un racionalizēta pasūtījumu apstrāde.
• Veselības aprūpe un dzīvības zinātnes :
  • Veselības aprūpē DDD var izmantot, lai modelētu pacientu ierakstus, medicīniskās diagnozes, ārstēšanas plānus un veselības aprūpes darbplūsmas. Precīzi attēlojot domēna jēdzienus, piemēram, pacientu demogrāfiskos datus, slimības vēsturi un klīniskos protokolus, DDD ļauj izstrādāt spēcīgas elektroniskās veselības reģistra (EHR) sistēmas, medicīniskās attēlveidošanas platformas un telemedicīnas lietojumprogrammas.
• Apdrošināšana :
  • Apdrošināšanas kompānijas pārvalda dažādus produktus, polises, prasības un parakstīšanas procesus. DDD var palīdzēt modelēt šīs sarežģītās domēna koncepcijas, nodrošinot tādas funkcijas kā politikas pārvaldība, prasību apstrāde, riska novērtējums un aktuāra analīze.
• Nekustamā īpašuma un īpašuma pārvaldīšana :
  • Nekustamais īpašums un īpašuma pārvaldīšana ietver dažādu īpašumu, nomas, īrnieku, uzturēšanas pieprasījumu un finanšu darījumu apstrādi. DDD var palīdzēt efektīvi modelēt šīs domēna koncepcijas, nodrošinot tādas funkcijas kā īpašumu sarakstu, nomas pārvaldību, īrnieku portālus un līdzekļu izsekošanu.

Reāls domēnu vadīta dizaina (DDD) piemērs

Problēmas paziņojums

Pieņemsim, ka mēs izstrādājam braucienu lietojumprogrammu ar nosaukumu RideX. Sistēma ļauj lietotājiem pieprasīt braucienus, vadītājiem pieņemt braukšanas pieprasījumus un atvieglo braucienu koordināciju starp lietotājiem un vadītājiem.

Sara Ali Khan vecums

Visuresošā valoda

1. Lietotājs : attiecas uz personām, kuras pieprasa braucienus, izmantojot RideX platformu.
2. Šoferis : attiecas uz personām, kas nodrošina braucienus lietotājiem, izmantojot RideX platformu.
3. Brauciena pieprasījums : attēlo lietotāja pieprasījumu pēc brauciena, norādot tādu informāciju kā saņemšanas vieta, galamērķis un brauciena preferences.
4. Braukt : attēlo vienu brauciena gadījumu, tostarp informāciju, piemēram, saņemšanas un izlaišanas vietas, cenas un ilgumu.
5. Brauciena statuss : atspoguļo brauciena pašreizējo statusu, piemēram, Pieprasīts, Akceptēts, Notiek vai Pabeigts.

Ierobežoti konteksti

1. Brauciena pārvaldības konteksts : atbildīgs par braucienu dzīves cikla pārvaldību, tostarp par brauciena pieprasījumiem, braucienu piešķiršanu vadītājiem un brauciena statusa atjauninājumiem.
2. Lietotāju pārvaldības konteksts : apstrādā lietotāja autentifikāciju, reģistrāciju un lietotājam specifiskas funkcijas, piemēram, braucienu vēsturi un maksājumu metodes.
3. Draiveru pārvaldības konteksts : pārvalda draivera autentifikāciju, reģistrāciju, pieejamības statusu un vadītājam raksturīgās funkcijas, piemēram, ieņēmumus un vērtējumus.

Entītijas un vērtību objekti

1. Lietotāja entītija : apzīmē reģistrētu RideX platformas lietotāju ar tādiem rekvizītiem kā lietotāja ID, e-pasts, parole un maksājuma informācija.
2. Vadītāja vienība : apzīmē reģistrētu vadītāju RideX platformā ar tādiem rekvizītiem kā vadītāja ID, transportlīdzekļa informācija un vadītāja statuss.
3. Brauciena pieprasījuma entītija : attēlo lietotāja pieprasījumu pēc brauciena, tostarp rekvizītus, piemēram, pieprasījuma ID, saņemšanas vietu, galamērķi un brauciena preferences.
4. Ride Entity : attēlo vienu brauciena gadījumu, tostarp rekvizītus, piemēram, brauciena ID, saņemšanas un izlaišanas vietas, cenu un brauciena statusu.
5. Atrašanās vietas vērtības objekts : apzīmē ģeogrāfisku atrašanās vietu ar tādiem parametriem kā platums un garums.

Agregāti

1. Braukšanas agregāts : sastāv no brauciena entītijas kā apkopotās saknes kopā ar saistītām entītijām, piemēram, brauciena pieprasījuma, lietotāja un vadītāja entītijām. Ride Aggregate ietver brauciena dzīves cikla pārvaldības loģiku, tostarp braukšanas pieprasījumu apstrādi, vadītāju piešķiršanu un brauciena statusa atjaunināšanu.

Repozitorijs

1. Ride Repository : nodrošina metodes ar braucieniem saistītu entītiju vaicāšanai un glabāšanai, piemēram, brauciena informācijas izgūšanai, brauciena statusa atjaunināšanai un ar braucieniem saistīto datu glabāšanai datu bāzē.

Pakalpojumi

1. Braucienu norīkošanas pakalpojums : atbildīgs par pieejamo vadītāju piešķiršanu braukšanas pieprasījumiem, pamatojoties uz tādiem faktoriem kā vadītāja pieejamība, tuvums paņemšanas vietai un lietotāja preferences.
2. Maksājumu pakalpojums : apstrādā maksājumu apstrādi par pabeigtiem braucieniem, aprēķinot cenas, apstrādājot maksājumus un atjauninot lietotāja un vadītāja maksājumu informāciju.

Domēna notikumi

1. RideRequestedEvent : attēlo notikumu, kas tiek aktivizēts, kad lietotājs pieprasa braucienu, ietverot tādu informāciju kā brauciena pieprasījuma informācija un lietotāja ID.
2. RideAcceptedEvent : apzīmē notikumu, kas tiek aktivizēts, kad vadītājs pieņem brauciena pieprasījumu, ietverot tādu informāciju kā brauciena ID, vadītāja ID un saņemšanas vieta.

Scenārija piemērs

1. Lietotājs, kurš pieprasa braucienu : lietotājs pieprasa braucienu, norādot savu saņemšanas vietu, galamērķi un brauciena preferences. RideX izveido jaunu brauciena pieprasījuma entītiju un aktivizē RideRequestedEvent.
2. Šoferis pieņem braucienu : vadītājs pieņem brauciena pieprasījumu no RideX platformas. RideX atjaunina brauciena statusu uz Accepted, piešķir braucienam vadītāju un aktivizē RideAcceptedEvent.
3. Brauciens notiek : lietotājs un vadītājs koordinē braucienu, brauciena statusam pārejot no Pieņemts uz Notiek, tiklīdz vadītājs sasniedz saņemšanas vietu.
4. Brauciena pabeigšana : pēc galamērķa sasniegšanas brauciena statuss tiek atjaunināts uz Pabeigts. RideX aprēķina maksu, apstrādā maksājumu un attiecīgi atjaunina lietotāja un vadītāja maksājuma informāciju.