Domain-Driven Design (DDD) is een benadering van softwareontwikkeling die zich richt op het begrijpen en modelleren van het probleemdomein waarbinnen een softwaresysteem opereert. Het benadrukt het belang van nauwe samenwerking met domeinexperts om een ​​diep inzicht te ontwikkelen in de fijne kneepjes en complexiteiten van het domein. DDD biedt een reeks principes, patronen en praktijken om ontwikkelaars te helpen domeinconcepten effectief vast te leggen en uit te drukken in hun softwareontwerpen.

Linux-bestanden

Belangrijke onderwerpen voor Domain-Driven Design (DDD)

• Wat is domeingestuurd ontwerp (DDD)?
• Belang van domeinkennis
• Strategisch Ontwerp in Domein-Driven Design (DDD)
• Tactische ontwerppatronen in domeingestuurd ontwerp (DDD)
• Voordelen van domeingestuurd ontwerp (DDD)
• Uitdagingen van domeingestuurd ontwerp (DDD)
• Gebruiksscenario's van domeingestuurd ontwerp (DDD)
• Realistisch voorbeeld van domeingestuurd ontwerp (DDD)

Wat is domeingestuurd ontwerp (DDD)?

Domein

Het verwijst naar het onderwerpgebied of de probleemruimte waarvoor het softwaresysteem wordt gebouwd. Het omvat de concepten, regels en processen uit de echte wereld die de software moet modelleren of ondersteunen. In een bankapplicatie omvat het domein bijvoorbeeld concepten als rekeningen, transacties, klanten en regelgeving met betrekking tot bankactiviteiten.

Gedreven

Gedreven houdt in dat het ontwerp van het softwaresysteem wordt gestuurd of beïnvloed door de kenmerken en eisen van het domein. Met andere woorden: de ontwerpbeslissingen zijn gebaseerd op een diepgaand begrip van het domein, en worden niet uitsluitend gedreven door technische overwegingen of implementatiedetails.

Ontwerp

Ontwerp verwijst naar het proces van het maken van een plan of blauwdruk voor het softwaresysteem. Dit omvat beslissingen over hoe het systeem zal worden gestructureerd, hoe verschillende componenten zullen samenwerken en hoe het systeem zijn doelstellingen zal vervullen functioneel En niet-functioneel vereisten. In de context van Domain-Driven Design ligt de focus op het ontwerpen van de software op een manier die de structuur en het gedrag van het domein accuraat weerspiegelt.

Domain-Driven Design is een concept geïntroduceerd door een programmeur Erik Evans in 2004 in zijn boek Domeingestuurd ontwerp: complexiteit aanpakken in het hart van software

Belang van domeinkennis

Stel dat we software hebben ontworpen met behulp van de nieuwste technologieën en infrastructuur en dat onze softwareontwerparchitectuur geweldig is, maar wanneer we deze software op de markt brengen, is het uiteindelijk de eindgebruiker die beslist of ons systeem geweldig is of niet. Ook als het systeem de bedrijfsbehoeften niet oplost, heeft niemand er iets aan. Hoe mooi het er ook uitziet of hoe goed de architectuur van de infrastructuur is.

Volgens Erik Evans Als we software ontwikkelen, moet onze focus niet in de eerste plaats op technologie liggen, maar in de eerste plaats op het bedrijfsleven. Herinneren,

Het is niet de taak van de klant om te weten wat hij wil – Steve Jobs

Strategisch Ontwerp in Domein-Driven Design (DDD)

Strategic Design in Domain-Driven Design (DDD) richt zich op het definiëren van de algehele architectuur en structuur van een softwaresysteem op een manier die aansluit bij het probleemdomein. Het behandelt vraagstukken op hoog niveau, zoals hoe domeinconcepten moeten worden georganiseerd, hoe het systeem in beheersbare delen kan worden verdeeld en hoe duidelijke grenzen tussen verschillende componenten kunnen worden vastgesteld.

Laten we eens kijken naar enkele sleutelconcepten binnen Strategic Design in Domain-Driven Design (DDD)

1. Begrensde contexten

• Een begrensde context vertegenwoordigt een specifiek gebied binnen het algemene probleemdomein waar een bepaald model of een bepaalde taal consistent van toepassing is.
• Verschillende delen van een systeem kunnen verschillende betekenissen hebben voor dezelfde termen, en een Bounded Context definieert expliciete grenzen waarbinnen die termen een specifieke betekenis hebben.
• Hierdoor kunnen teams modellen ontwikkelen die zijn afgestemd op specifieke contexten, zonder dat er verwarring of inconsistenties ontstaan.
• Bounded Contexts helpen de complexiteit te beheersen door een groot, complex domein op te splitsen in kleinere, beter beheersbare delen.

2. Contexttoewijzing

• Context Mapping is het proces van het definiëren van de relaties en interacties tussen verschillende begrensde contexten.
• Het gaat om het identificeren van gebieden van overlap of integratie tussen contexten en het opzetten van communicatiekanalen en overeenkomsten daartussen.
• Context Mapping helpt ervoor te zorgen dat verschillende delen van het systeem effectief kunnen samenwerken, terwijl er toch duidelijke grenzen tussen de delen behouden blijven.
• Er zijn verschillende patronen en technieken voor Context Mapping, zoals Partnership, Shared Kernel en Customer-Leverancier.

3. Strategische patronen

• Strategische patronen zijn algemene richtlijnen of principes voor het organiseren van de architectuur van een softwaresysteem op een manier die aansluit bij het probleemdomein.
• Deze patronen helpen gemeenschappelijke uitdagingen bij het ontwerpen van complexe systemen aan te pakken en bieden bewezen benaderingen voor het effectief structureren van het systeem.
• Voorbeelden van strategische patronen zijn onder meer aggregaten, domeingebeurtenissen en anticorruptielaag.
• Deze patronen bieden oplossingen voor terugkerende problemen bij domeingestuurd ontwerp en helpen ervoor te zorgen dat de architectuur van het systeem de onderliggende domeinconcepten nauwkeurig weerspiegelt.

4. Gedeelde kernel

• Gedeelde kernel is een strategisch patroon dat betrekking heeft op het identificeren van gemeenschappelijke gebieden tussen verschillende begrensde contexten en het opzetten van een gedeelde subset van het domeinmodel dat door meerdere contexten wordt gebruikt.
• Deze gedeelde subset, of kernel, helpt de samenwerking en integratie tussen contexten te vergemakkelijken, terwijl elke context toch zijn eigen onderscheidende model kan behouden.
• Gedeelde Kernel moet verstandig worden gebruikt, omdat het afhankelijkheden tussen contexten introduceert en tot koppeling kan leiden als het niet zorgvuldig wordt beheerd.

5. Anticorruptielaag (ACL)

• De anticorruptielaag is een ander strategisch patroon dat helpt een systeem te beschermen tegen de invloed van externe of oudere systemen die verschillende modellen of talen gebruiken.
• Een ACL fungeert als vertaallaag tussen het externe systeem en het kerndomeinmodel, waarbij gegevens en berichten indien nodig worden getransformeerd om compatibiliteit te garanderen.
• Hierdoor kan het kerndomeinmodel puur en gefocust blijven op het probleemdomein, terwijl het indien nodig nog steeds kan worden geïntegreerd met externe systemen.

6. Alomtegenwoordige taal

Ubiquitous Language verwijst naar een gedeelde woordenschat of taal die consistent en universeel wordt gebruikt door alle belanghebbenden die betrokken zijn bij de ontwikkeling van een softwaresysteem. Deze taal bestaat uit termen, zinsneden en concepten die domeinkennis en concepten nauwkeurig weergeven.

Enkele van de belangrijkste principes van Ubiquitous Language zijn:

• Gedeeld begrip : Het primaire doel van Ubiquitous Language is het tot stand brengen van een gedeeld begrip van het probleemdomein onder alle leden van het ontwikkelingsteam, inclusief ontwikkelaars, domeinexperts, bedrijfsanalisten en belanghebbenden. Door een gemeenschappelijke taal te gebruiken, kunnen alle betrokkenen effectiever communiceren en domeinconcepten en -vereisten nauwkeuriger overbrengen.
• Consistentie en duidelijkheid : Ubiquitous Language bevordert consistentie en duidelijkheid in de communicatie door nauwkeurige en ondubbelzinnige terminologie te gebruiken. Elke term of zinsnede in de taal moet een duidelijke en overeengekomen betekenis hebben,
• Afstemming met bedrijfsconcepten : Het taalgebruik in DDD moet nauw aansluiten bij de terminologie en concepten die in het zakelijke domein worden gebruikt. Het moet de manier weerspiegelen waarop domeinexperts over het probleemdomein denken en praten, en ervoor zorgen dat de software de concepten en processen uit de echte wereld accuraat weergeeft.
• Evolutionaire aard : Alomtegenwoordige taal is niet statisch, maar evolueert in de loop van de tijd naarmate het team een ​​dieper inzicht krijgt in het domein en naarmate de vereisten veranderen. Het moet zich aanpassen aan nieuwe inzichten, ontdekkingen of veranderingen in zakelijke prioriteiten, en ervoor zorgen dat de taal tijdens het ontwikkelingsproces relevant en up-to-date blijft.

Tactische ontwerppatronen in domeingestuurd ontwerp (DDD)

Bij Domain-Driven Design (DDD) zijn tactische ontwerppatronen specifieke strategieën of technieken die worden gebruikt om het domeinmodel binnen een softwaresysteem te structureren en te organiseren. Deze patronen helpen ontwikkelaars effectief de complexiteit van het domein vast te leggen, terwijl ze ook de onderhoudbaarheid, flexibiliteit en schaalbaarheid bevorderen.

Laten we eens kijken naar enkele van de belangrijkste tactische ontwerppatronen in DDD:

sql concat

1. Entiteit

Een entiteit is een domeinobject met een duidelijke identiteit en levenscyclus. Entiteiten worden gekenmerkt door hun unieke identificatiegegevens en veranderlijke status. Ze omvatten gedrag en gegevens gerelateerd aan een specifiek concept binnen het domein.

In een banktoepassing kan bijvoorbeeld aBankAccount>entiteit kan eigenschappen hebben zoals rekeningnummer, saldo en eigenaar, samen met methoden om geld te storten, op te nemen of over te dragen.

2. Waardeobject

Een waardeobject is een domeinobject dat een conceptueel onveranderlijke waarde vertegenwoordigt. In tegenstelling tot entiteiten hebben waardeobjecten geen duidelijke identiteit en worden ze doorgaans gebruikt om attributen of eigenschappen van entiteiten weer te geven. Waardeobjecten zijn gelijkheidsvergelijkbaar op basis van hun eigenschappen, in plaats van hun identiteit.

Bijvoorbeeld, eenMoney>waarde-object kan een specifieke hoeveelheid valuta vertegenwoordigen, met daarin eigenschappen zoals valutatype en bedrag.

3. Samenvoegen

• Een aggregaat is een cluster van domeinobjecten die als één eenheid worden behandeld met het oog op gegevensconsistentie en transactionele integriteit.
• Aggregaten bestaan ​​uit een of meer entiteiten en waardeobjecten, waarbij één entiteit is aangewezen als de aggregatiewortel.
• De aggregaatwortel dient als toegangspunt voor toegang tot en wijziging van de interne status van het aggregaat.
• Aggregaten dwingen consistentiegrenzen af ​​binnen het domeinmodel en zorgen ervoor dat wijzigingen in gerelateerde objecten atomair worden aangebracht.

In een e-commercesysteem kan bijvoorbeeld eenOrder>aggregaat kan bestaan ​​uit entiteiten zoalsOrderItem>EnCustomer>, met deOrder>entiteit die als de aggregatiewortel fungeert.

4. Bewaarplaats

• Een repository is een mechanisme voor het abstraheren van datatoegang en persistentielogica uit het domeinmodel.
• Repository's bieden een gestandaardiseerde interface voor het opvragen en opslaan van domeinobjecten, waarbij de details worden verborgen over hoe gegevens worden opgehaald of opgeslagen. Repository's omvatten de logica voor het vertalen tussen domeinobjecten en onderliggende mechanismen voor gegevensopslag, zoals databases of externe services.
• Door het domeinmodel los te koppelen van de zorgen over gegevenstoegang, maken repositories een grotere flexibiliteit en onderhoudbaarheid mogelijk.

Bijvoorbeeld, eenCustomerRepository>zou methoden kunnen bieden voor het opvragen en opslaanCustomer>entiteiten.

5. Fabriek

• Een fabriek is een scheppingspatroon gebruikt om de logica in te kapselen voor het maken van instanties van complexe domeinobjecten. Fabrieken abstraheren het proces van het instantiëren van objecten, waardoor klanten objecten kunnen maken zonder de details van hun constructie te hoeven kennen.
• Fabrieken zijn met name handig voor het maken van objecten die complexe initialisatielogica vereisen of meerdere stappen vereisen.

Bijvoorbeeld, eenProductFactory>kan verantwoordelijk zijn voor het maken van exemplaren vanProduct>entiteiten met standaardconfiguraties.

6. Dienst

• Een service is een domeinobject dat een gedrag of handeling vertegenwoordigt die van nature niet tot een specifieke entiteit of waardeobject behoort.
• Services omvatten domeinlogica die op meerdere objecten werkt of interacties tussen objecten orkestreert.
• Services zijn doorgaans staatloos en richten zich op het uitvoeren van specifieke taken of het afdwingen van domeinregels.

Bijvoorbeeld, eenOrderService>kan methoden bieden voor het verwerken van bestellingen, het toepassen van kortingen en het berekenen van verzendkosten.

Voordelen van domeingestuurd ontwerp (DDD)

• Gedeeld begrip :
  • Het stimuleert de samenwerking tussen domeinexperts, ontwikkelaars en belanghebbenden.
  • Door een gedeeld begrip van het probleemdomein aan te moedigen via de alomtegenwoordige taal, kunnen teams effectiever communiceren en ervoor zorgen dat de software nauwkeurig de behoeften en vereisten van het bedrijf weerspiegelt.
• Focus op het kerndomein :
  • Het helpt teams het kerndomein van de applicatie te identificeren en te prioriteren: de gebieden van het systeem die de meeste waarde voor het bedrijf bieden. Door de ontwikkelingsinspanningen op het kerndomein te concentreren, kunnen teams functionaliteit leveren die direct aansluit bij de bedrijfsdoelstellingen en de software onderscheidt van de concurrentie.
• Veerkracht tegen verandering :
  • Het legt de nadruk op het ontwerpen van softwaresystemen die bestand zijn tegen verandering door het domein te modelleren op een manier die de inherente complexiteiten en onzekerheden van het probleemdomein weerspiegelt.
  • Door verandering te omarmen als een natuurlijk onderdeel van softwareontwikkeling, kunnen teams effectiever reageren op veranderende bedrijfsbehoeften en marktomstandigheden.
• Duidelijke scheiding van zorgen :
  • DDD moedigt een duidelijke scheiding van zorgen aan tussen domeinlogica, infrastructuurproblemen en gebruikersinterfaceproblemen. Door domeinlogica te isoleren van technische details en infrastructuurproblemen, kunnen teams een schoon en gericht domeinmodel behouden dat onafhankelijk is van specifieke implementatiedetails of technologische keuzes.
• Verbeterde testbaarheid :
  • Het bevordert het gebruik van domeinobjecten met goed gedefinieerde grenzen en gedrag, waardoor het gemakkelijker wordt om betere en gerichte tests te schrijven die de juistheid van domeinlogica verifiëren.
  • Door softwaresystemen te ontwerpen met het oog op testbaarheid kunnen teams ervoor zorgen dat wijzigingen in de codebase veilig en voorspelbaar zijn, waardoor het risico op regressies of onbedoelde bijwerkingen wordt verkleind.
• Ondersteuning voor complexe bedrijfsregels :
  • Het biedt patronen en technieken voor het modelleren en implementeren van complexe bedrijfsregels en workflows binnen het domeinmodel.
  • Door bedrijfsregels expliciet in het domeinmodel weer te geven, kunnen teams ervoor zorgen dat de software de complexiteit van het bedrijfsdomein accuraat weerspiegelt en domeinspecifieke beperkingen en vereisten afdwingt.
• Afstemming op bedrijfsdoelen :
  • Uiteindelijk is het de bedoeling om de inspanningen voor softwareontwikkeling af te stemmen op de strategische doelen en doelstellingen van het bedrijf. Door zich te concentreren op het begrijpen en modelleren van het probleemdomein kunnen teams softwareoplossingen leveren die de bedrijfsdoelstellingen rechtstreeks ondersteunen, innovatie stimuleren en waarde creëren voor belanghebbenden en eindgebruikers.

Uitdagingen van domeingestuurd ontwerp (DDD)

• Complexiteit :
  • DDD kan complexiteit introduceren, vooral in grote en complexe domeinen.
  • Het nauwkeurig modelleren van ingewikkelde bedrijfsdomeinen vereist een diepgaand begrip van het domein en kan gepaard gaan met het omgaan met ambiguïteit en onzekerheid. Het effectief beheren van deze complexiteit vereist een zorgvuldige planning, samenwerking en expertise.
• Alomtegenwoordige taaladoptie :
  • Het opzetten en onderhouden van een alomtegenwoordige taal – een gedeeld vocabulaire dat domeinconcepten accuraat weergeeft – kan een uitdaging zijn. Het vereist samenwerking tussen ontwikkelaars en domeinexperts om domeintermen en -betekenissen te identificeren en er overeenstemming over te bereiken.
  • Om consensus te bereiken over de alomtegenwoordige taal kan het nodig zijn communicatiebarrières te overwinnen en verschillen in terminologie en perspectieven met elkaar te verzoenen.
• Begrensde contextuitlijning :
  • In grote en complexe domeinen kunnen verschillende delen van het domein verschillende modellen en begrensde contexten hebben. Het kan een uitdaging zijn om deze begrensde contexten op één lijn te brengen en de consistentie ertussen te garanderen.
  • Het vereist duidelijke communicatie, samenwerking en coördinatie tussen teams die aan verschillende delen van het domein werken om inconsistenties en conflicten te voorkomen.
• Technische complexiteit :
  • Het effectief implementeren van DDD-principes en -patronen kan het adopteren van nieuwe technologieën, raamwerken en architecturale benaderingen vereisen. Het integreren van DDD met bestaande systemen of oudere codebases kan complex zijn en vereist mogelijk een refactoring of herontwerp van bestaande code om deze in lijn te brengen met de DDD-principes.
  • Technische uitdagingen zoals prestaties, schaalbaarheid en onderhoudbaarheid moeten zorgvuldig worden aangepakt om het succes van DDD-adoptie te garanderen.
• Weerstand tegen verandering :
  • Het introduceren van DDD kan op weerstand stuiten van teamleden die gewend zijn aan traditionele ontwikkelingsbenaderingen of die DDD als te complex of onpraktisch beschouwen.
  • Het overwinnen van weerstand tegen verandering vereist effectieve communicatie, educatie en leiderschap om de voordelen van DDD aan te tonen en zorgen en scepticisme weg te nemen.
• Over-engineering :
  • Er bestaat een risico op over-engineering bij het toepassen van DDD, waarbij teams zich te veel concentreren op het modelleren van complexe domeinconcepten en het introduceren van onnodige abstracties of complexiteit. Het vinden van de juiste balans tussen eenvoud en expressiviteit is cruciaal om te voorkomen dat het ontwerp en de implementatie te ingewikkeld worden.

Gebruiksscenario's van domeingestuurd ontwerp (DDD)

• Financieren en bankieren :
  • In de financiële sector kan DDD worden gebruikt om complexe financiële instrumenten, transacties en wettelijke vereisten te modelleren. Door domeinconcepten zoals rekeningen, transacties en portefeuilles nauwkeurig weer te geven, helpt DDD de integriteit en consistentie van financiële systemen te garanderen. Het maakt ook beter risicobeheer, compliance en rapportage mogelijk.
• E-commerce en detailhandel :
  • E-commerceplatforms hebben vaak te maken met complexe domeinconcepten zoals productcatalogi, voorraadbeheer, prijzen en klantbestellingen. DDD kan helpen deze concepten effectief te modelleren, waardoor functies zoals gepersonaliseerde aanbevelingen, dynamische prijzen en gestroomlijnde orderverwerking mogelijk worden.
• Gezondheidszorg en levenswetenschappen :
  • In de gezondheidszorg kan DDD worden gebruikt om patiëntendossiers, medische diagnoses, behandelplannen en zorgworkflows te modelleren. Door domeinconcepten zoals demografische gegevens van patiënten, medische geschiedenis en klinische protocollen nauwkeurig weer te geven, maakt DDD de ontwikkeling mogelijk van robuuste systemen voor elektronische medische dossiers (EPD), platforms voor medische beeldvorming en telegeneeskundetoepassingen.
• Verzekering :
  • Verzekeringsmaatschappijen beheren diverse producten, polissen, claims en acceptatieprocessen. DDD kan helpen bij het modelleren van deze complexe domeinconcepten, waardoor functies als polisbeheer, claimverwerking, risicobeoordeling en actuariële analyse mogelijk worden.
• Vastgoed en vastgoedbeheer :
  • Bij vastgoed en vastgoedbeheer gaat het om de afhandeling van diverse eigendommen, huurovereenkomsten, huurders, onderhoudsaanvragen en financiële transacties. DDD kan helpen deze domeinconcepten effectief te modelleren, waardoor functies mogelijk worden zoals vastgoedvermeldingen, huurbeheer, huurdersportals en het volgen van activa.

Realistisch voorbeeld van domeingestuurd ontwerp (DDD)

Probleemstelling

Laten we zeggen dat we een app voor het aanbieden van ritjes aan het ontwikkelen zijn, genaamd RideX. Met het systeem kunnen gebruikers ritten aanvragen, kunnen chauffeurs ritaanvragen accepteren en wordt de coördinatie van ritten tussen gebruikers en chauffeurs vergemakkelijkt.

Java-operatoren

Alomtegenwoordige taal

1. Gebruiker : Verwijst naar personen die ritten aanvragen via het RideX-platform.
2. Bestuurder : Verwijst naar personen die ritten aanbieden aan gebruikers via het RideX-platform.
3. Ritverzoek : vertegenwoordigt het verzoek van een gebruiker voor een rit, met details zoals ophaallocatie, bestemming en ritvoorkeuren.
4. Rijden : vertegenwoordigt één exemplaar van een rit, inclusief details zoals ophaal- en afleverlocaties, tarief en duur.
5. Ritstatus : vertegenwoordigt de huidige status van een rit, zoals Aangevraagd, Geaccepteerd, In uitvoering of Voltooid.

Gelimiteerde contexten

1. Context van ritbeheer : Verantwoordelijk voor het beheer van de levenscyclus van ritten, inclusief ritaanvragen, rittoewijzingen aan chauffeurs en ritstatusupdates.
2. Context voor gebruikersbeheer : Verwerkt gebruikersauthenticatie, registratie en gebruikersspecifieke functies zoals ritgeschiedenis en betaalmethoden.
3. Context van stuurprogrammabeheer : Beheert bestuurdersauthenticatie, registratie, beschikbaarheidsstatus en bestuurderspecifieke functies zoals inkomsten en beoordelingen.

Entiteiten en waardeobjecten

1. Gebruikersentiteit : Vertegenwoordigt een geregistreerde gebruiker van het RideX-platform, met eigenschappen zoals gebruikers-ID, e-mailadres, wachtwoord en betalingsinformatie.
2. Bestuurder Entiteit : Vertegenwoordigt een geregistreerde bestuurder op het RideX-platform, met eigenschappen zoals bestuurders-ID, voertuiggegevens en bestuurdersstatus.
3. Ritaanvraagentiteit : vertegenwoordigt het verzoek van een gebruiker voor een rit, inclusief eigenschappen zoals aanvraag-ID, ophaallocatie, bestemming en ritvoorkeuren.
4. Rit entiteit : vertegenwoordigt één exemplaar van een rit, inclusief eigenschappen zoals rit-ID, ophaal- en afleverlocaties, tarief en ritstatus.
5. Locatiewaardeobject : vertegenwoordigt een geografische locatie, met eigenschappen zoals breedtegraad en lengtegraad.

Aggregaten

1. Rijd aggregaat : Bestaat uit de Ritentiteit als de verzamelde root, samen met gerelateerde entiteiten zoals Ritverzoek-, Gebruiker- en Bestuurderentiteiten. De Ride Aggregate omvat de logica voor het beheren van de levenscyclus van een rit, inclusief het afhandelen van ritaanvragen, het toewijzen van chauffeurs en het bijwerken van de ritstatus.

Opslagplaats

1. Ritopslagplaats : biedt methoden voor het opvragen en opslaan van ritgerelateerde entiteiten, zoals het ophalen van ritgegevens, het bijwerken van de ritstatus en het opslaan van ritgerelateerde gegevens in de database.

Diensten

1. Rittoewijzingsservice : Verantwoordelijk voor het toewijzen van beschikbare chauffeurs aan ritaanvragen op basis van factoren zoals de beschikbaarheid van chauffeurs, de nabijheid van de ophaallocatie en gebruikersvoorkeuren.
2. Betaalservice : Verwerkt de betalingsverwerking voor voltooide ritten, het berekenen van tarieven, het verwerken van betalingen en het bijwerken van betalingsgegevens van gebruikers en chauffeurs.

Domeingebeurtenissen

1. RideRequestedEvent : vertegenwoordigt een gebeurtenis die wordt geactiveerd wanneer een gebruiker een rit aanvraagt, met informatie zoals de details van de ritaanvraag en de gebruikers-ID.
2. RideAcceptedEvent : vertegenwoordigt een gebeurtenis die wordt geactiveerd wanneer een bestuurder een ritverzoek accepteert, met informatie zoals de rit-ID, bestuurders-ID en ophaallocatie.

Voorbeeldscenario

1. Gebruiker die een rit aanvraagt : een gebruiker vraagt ​​een rit aan door zijn ophaallocatie, bestemming en ritvoorkeuren op te geven. RideX maakt een nieuwe ritaanvraagentiteit en activeert een RideRequestedEvent.
2. Bestuurder die een rit accepteert : Een bestuurder accepteert een ritaanvraag van het RideX-platform. RideX werkt de ritstatus bij naar Geaccepteerd, wijst de bestuurder toe aan de rit en activeert een RideAcceptedEvent.
3. Rit bezig : De gebruiker en de chauffeur coördineren de rit, waarbij de ritstatus overgaat van Geaccepteerd naar In uitvoering zodra de chauffeur de ophaallocatie bereikt.
4. Voltooiing van de rit : Na het bereiken van de bestemming wordt de ritstatus bijgewerkt naar Voltooid. RideX berekent het tarief, verwerkt de betaling en werkt de betalingsinformatie van de gebruiker en chauffeur dienovereenkomstig bij.