Domain-Driven Design (DDD) to podejście do tworzenia oprogramowania, które koncentruje się na zrozumieniu i modelowaniu domeny problemowej, w obrębie której działa system oprogramowania. Podkreśla znaczenie ścisłej współpracy z ekspertami w dziedzinie w celu pogłębienia zrozumienia zawiłości i złożoności domeny. DDD zapewnia zestaw zasad, wzorców i praktyk pomagających programistom skutecznie uchwycić i wyrazić koncepcje domeny w projektach oprogramowania.

globalna zmienna JavaScript

Ważne tematy dotyczące projektowania opartego na domenie (DDD)

• Co to jest projektowanie oparte na domenie (DDD)?
• Znaczenie wiedzy dziedzinowej
• Projektowanie strategiczne w projektowaniu opartym na domenie (DDD)
• Taktyczne wzorce projektowe w projektowaniu opartym na domenie (DDD)
• Korzyści z projektowania opartego na domenie (DDD)
• Wyzwania związane z projektowaniem opartym na domenie (DDD)
• Przypadki użycia projektowania opartego na domenie (DDD)
• Rzeczywisty przykład projektowania opartego na domenie (DDD)

Co to jest projektowanie oparte na domenie (DDD)?

Domena

Odnosi się do obszaru tematycznego lub przestrzeni problemowej, do rozwiązania której tworzony jest system oprogramowania. Obejmuje rzeczywiste koncepcje, zasady i procesy, które oprogramowanie ma modelować lub wspierać. Na przykład w aplikacji bankowej domena zawiera pojęcia takie jak rachunki, transakcje, klienci i regulacje związane z operacjami bankowymi.

Napędzany

Napędzany oznacza, że ​​projekt systemu oprogramowania jest kierowany lub pod wpływem cech i wymagań domeny. Innymi słowy, decyzje projektowe opierają się na głębokim zrozumieniu dziedziny, a nie wyłącznie na względach technicznych lub szczegółach implementacji.

Projekt

Projektowanie odnosi się do procesu tworzenia planu lub projektu systemu oprogramowania. Obejmuje to decyzje dotyczące struktury systemu, interakcji różnych komponentów i sposobu, w jaki system będzie realizował swoje zadania funkcjonalny I niefunkcjonalny wymagania. W kontekście Domain-Driven Design nacisk kładzie się na projektowanie oprogramowania w sposób, który dokładnie odzwierciedla strukturę i zachowanie domeny.

Domain-Driven Design to koncepcja wprowadzona przez programistę Erica Evansa w swojej książce w 2004 r Projektowanie oparte na domenie: radzenie sobie ze złożonością w sercu oprogramowania

Znaczenie wiedzy dziedzinowej

Załóżmy, że zaprojektowaliśmy oprogramowanie przy użyciu najnowszych technologii i infrastruktury, a nasza architektura projektowania oprogramowania jest niesamowita, ale kiedy wypuszczamy to oprogramowanie na rynek, ostatecznie to użytkownik końcowy decyduje, czy nasz system jest świetny, czy nie. Także jeśli system nie rozwiązuje potrzeb biznesowych, to nikomu nie będzie przydatny. Nieważne, jak ładnie wygląda i jak dobra jest architektura jego infrastruktury.

Według Erica Evansa , Kiedy tworzymy oprogramowanie, nie powinniśmy skupiać się głównie na technologii, ale raczej na biznesie. Pamiętać,

Zadaniem klienta nie jest wiedzieć, czego chce – Steve Jobs

Projektowanie strategiczne w projektowaniu opartym na domenie (DDD)

Projektowanie strategiczne w projektowaniu opartym na domenie (DDD) koncentruje się na definiowaniu ogólnej architektury i struktury systemu oprogramowania w sposób zgodny z dziedziną problemu. Rozwiązuje problemy wysokiego szczebla, takie jak organizacja koncepcji dziedzin, podział systemu na łatwe do zarządzania części i ustalenie wyraźnych granic między różnymi komponentami.

Przyjrzyjmy się kilku kluczowym koncepcjom z zakresu projektowania strategicznego w projektowaniu opartym na domenie (DDD)

1. Konteksty ograniczone

• Kontekst ograniczony reprezentuje konkretny obszar w ramach ogólnej dziedziny problemu, w którym spójnie stosuje się określony model lub język.
• Różne części systemu mogą mieć różne znaczenia dla tych samych terminów, a kontekst ograniczony definiuje wyraźne granice, w obrębie których te terminy mają określone znaczenia.
• Umożliwia to zespołom opracowywanie modeli dostosowanych do konkretnych kontekstów bez wprowadzania zamieszania i niespójności.
• Ograniczone konteksty pomagają zarządzać złożonością, dzieląc dużą, złożoną domenę na mniejsze, łatwiejsze w zarządzaniu części.

2. Mapowanie kontekstu

• Mapowanie kontekstu to proces definiowania relacji i interakcji pomiędzy różnymi ograniczonymi kontekstami.
• Polega na identyfikacji obszarów nakładania się lub integracji kontekstów oraz ustaleniu kanałów komunikacji i porozumień między nimi.
• Mapowanie kontekstu pomaga zapewnić efektywną współpracę różnych części systemu przy jednoczesnym zachowaniu wyraźnych granic między nimi.
• Istnieją różne wzorce i techniki mapowania kontekstu, takie jak partnerstwo, wspólne jądro i klient-dostawca.

3. Wzorce strategiczne

• Wzorce strategiczne to ogólne wytyczne lub zasady organizacji architektury systemu oprogramowania w sposób zgodny z dziedziną problemu.
• Wzorce te pomagają stawić czoła typowym wyzwaniom związanym z projektowaniem złożonych systemów i zapewniają sprawdzone podejścia do skutecznego konstruowania systemu.
• Przykłady wzorców strategicznych obejmują agregaty, zdarzenia domeny i warstwę antykorupcyjną.
• Wzorce te zapewniają rozwiązania powtarzających się problemów w projektowaniu opartym na domenie i pomagają zapewnić, że architektura systemu dokładnie odzwierciedla podstawowe koncepcje domeny.

4. Wspólne jądro

• Wspólne jądro to wzorzec strategiczny, który obejmuje identyfikację obszarów wspólnych między różnymi ograniczonymi kontekstami i ustanowienie wspólnego podzbioru modelu domeny, który jest używany przez wiele kontekstów.
• Ten współdzielony podzbiór, czyli jądro, ułatwia współpracę i integrację między kontekstami, jednocześnie umożliwiając każdemu kontekstowi utrzymanie własnego, odrębnego modelu.
• Współdzielonego jądra należy używać rozsądnie, ponieważ wprowadza zależności między kontekstami i może prowadzić do sprzężeń, jeśli nie jest zarządzane ostrożnie.

ciąg zastępczy Java

5. Warstwa antykorupcyjna (ACL)

• Warstwa antykorupcyjna to kolejny strategiczny wzorzec, który pomaga chronić system przed wpływem zewnętrznych lub starszych systemów, które korzystają z różnych modeli lub języków.
• Lista ACL działa jako warstwa translacyjna pomiędzy systemem zewnętrznym a podstawowym modelem domeny, przekształcając dane i komunikaty zgodnie z potrzebami, aby zapewnić kompatybilność.
• Dzięki temu podstawowy model domeny pozostaje czysty i koncentruje się na domenie problemowej, a jednocześnie w razie potrzeby integruje się z systemami zewnętrznymi.

6. Język wszechobecny

Język wszechobecny odnosi się do wspólnego słownictwa lub języka, który jest używany konsekwentnie i powszechnie przez wszystkich interesariuszy zaangażowanych w rozwój systemu oprogramowania. Język ten składa się z terminów, zwrotów i pojęć, które dokładnie reprezentują wiedzę i koncepcje danej dziedziny.

Oto niektóre z kluczowych zasad języka wszechobecnego:

• Wspólne zrozumienie : Podstawowym celem języka Ubiquitous Language jest ustalenie wspólnego zrozumienia domeny problemowej wśród wszystkich członków zespołu programistów, w tym programistów, ekspertów domenowych, analityków biznesowych i interesariuszy. Używając wspólnego języka, wszyscy zaangażowani mogą komunikować się skuteczniej i dokładniej przekazywać koncepcje i wymagania dotyczące domeny.
• Spójność i przejrzystość : Wszechobecny Język promuje spójność i przejrzystość w komunikacji poprzez stosowanie precyzyjnej i jednoznacznej terminologii. Każdy termin lub fraza w języku powinna mieć jasne i uzgodnione znaczenie,
• Dostosowanie do koncepcji biznesowych : Język używany w DDD powinien być ściśle zgodny z terminologią i koncepcjami używanymi w domenie biznesowej. Powinno odzwierciedlać sposób, w jaki eksperci domeny myślą i mówią o dziedzinie problematycznej, zapewniając, że oprogramowanie dokładnie odzwierciedla koncepcje i procesy ze świata rzeczywistego.
• Natura ewolucyjna : Wszechobecny Język nie jest statyczny, ale ewoluuje w miarę upływu czasu, gdy zespół zyskuje głębsze zrozumienie domeny i gdy zmieniają się wymagania. Powinien dostosowywać się, aby odzwierciedlać nowe spostrzeżenia, odkrycia lub zmiany w priorytetach biznesowych, zapewniając, że język pozostaje odpowiedni i aktualny przez cały proces rozwoju.

Taktyczne wzorce projektowe w projektowaniu opartym na domenie (DDD)

W projektowaniu opartym na domenie (DDD) taktyczne wzorce projektowe to specyficzne strategie lub techniki stosowane do strukturyzowania i organizowania modelu domeny w systemie oprogramowania. Wzorce te pomagają programistom skutecznie uchwycić złożoność domeny, jednocześnie promując łatwość konserwacji, elastyczność i skalowalność.

Przyjrzyjmy się niektórym kluczowym wzorcom projektowania taktycznego w DDD:

1. Podmiot

Jednostka to obiekt domeny, który ma odrębną tożsamość i cykl życia. Jednostki charakteryzują się unikalnymi identyfikatorami i zmiennym stanem. Zawierają zachowania i dane związane z konkretną koncepcją w obrębie domeny.

Na przykład w aplikacji bankowej aBankAccount>podmiot może mieć właściwości, takie jak numer konta, saldo i właściciel, a także metody wpłacania, wypłacania lub przesyłania środków.

2. Obiekt wartości

Obiekt wartości to obiekt domeny, który reprezentuje koncepcyjnie niezmienną wartość. W przeciwieństwie do jednostek, obiekty wartości nie mają odrębnej tożsamości i zazwyczaj są używane do reprezentowania atrybutów lub właściwości jednostek. Obiekty wartości można porównywać pod względem równości na podstawie ich właściwości, a nie tożsamości.

Na przykład:Money>obiekt wartości może reprezentować określoną kwotę waluty, obejmując właściwości, takie jak typ i kwota waluty.

3. Agregat

• Agregat to klaster obiektów domeny, które są traktowane jako pojedyncza jednostka w celu zapewnienia spójności danych i integralności transakcyjnej.
• Agregaty składają się z jednej lub większej liczby jednostek i obiektów wartości, przy czym jedna jednostka jest wyznaczona jako główny element agregatu.
• Agregat główny służy jako punkt wejścia umożliwiający dostęp do wewnętrznego stanu agregatu i modyfikowanie go.
• Agregaty wymuszają granice spójności w modelu domeny, zapewniając, że zmiany w powiązanych obiektach są wprowadzane niepodzielnie.

Na przykład w systemie handlu elektronicznego anOrder>agregat może składać się z bytów takich jakOrderItem>ICustomer>, zOrder>jednostka służąca jako zagregowany korzeń.

4. Repozytorium

• Repozytorium to mechanizm wyodrębniania logiki dostępu do danych i trwałości z modelu domeny.
• Repozytoria zapewniają ustandaryzowany interfejs do odpytywania i przechowywania obiektów domeny, ukrywając szczegóły dotyczące sposobu pobierania lub przechowywania danych. Repozytoria zawierają logikę translacji pomiędzy obiektami domeny i podstawowymi mechanizmami przechowywania danych, takimi jak bazy danych lub usługi zewnętrzne.
• Oddzielając model domeny od problemów związanych z dostępem do danych, repozytoria zapewniają większą elastyczność i łatwość konserwacji.

Na przykład:CustomerRepository>może zapewnić metody odpytywania i przechowywaniaCustomer>podmioty.

5. Fabryka

• Fabryka to A wzór twórczy używany do hermetyzacji logiki tworzenia instancji złożonych obiektów domeny. Fabryki abstrahują proces tworzenia obiektów, umożliwiając klientom tworzenie obiektów bez konieczności znajomości szczegółów ich konstrukcji.
• Fabryki są szczególnie przydatne do tworzenia obiektów wymagających złożonej logiki inicjalizacji lub obejmujących wiele kroków.

Na przykład:ProductFactory>może być odpowiedzialny za tworzenie instancjiProduct>jednostki z konfiguracjami domyślnymi.

6. Serwis

• Usługa to obiekt domeny reprezentujący zachowanie lub operację, która w naturalny sposób nie należy do żadnej konkretnej jednostki lub obiektu wartości.
• Usługi hermetyzują logikę domeny, która działa na wielu obiektach lub organizuje interakcje między obiektami.
• Usługi są zazwyczaj bezstanowe i skupiają się na wykonywaniu określonych zadań lub egzekwowaniu reguł domeny.

Na przykład:OrderService>może udostępniać metody przetwarzania zamówień, stosowania rabatów i obliczania kosztów wysyłki.

Korzyści z projektowania opartego na domenie (DDD)

• Wspólne zrozumienie :
  • Zachęca do współpracy między ekspertami dziedzinowymi, programistami i zainteresowanymi stronami.
  • Zachęcając do wspólnego zrozumienia dziedziny problematycznej za pomocą wszechobecnego języka, zespoły mogą komunikować się skuteczniej i mieć pewność, że oprogramowanie dokładnie odzwierciedla potrzeby i wymagania firmy.
• Skoncentruj się na domenie podstawowej :
  • Pomaga zespołom zidentyfikować i ustalić priorytety podstawowej domeny aplikacji — obszarów systemu, które zapewniają największą wartość dla firmy. Koncentrując wysiłki programistyczne na domenie podstawowej, zespoły mogą dostarczać funkcjonalność, która bezpośrednio realizuje cele biznesowe i odróżnia oprogramowanie od konkurencji.
• Odporność na zmiany :
  • Kładzie nacisk na projektowanie systemów oprogramowania odpornych na zmiany poprzez modelowanie domeny w sposób odzwierciedlający nieodłączną złożoność i niepewność domeny problemowej.
  • Uznając zmiany za naturalną część tworzenia oprogramowania, zespoły mogą skuteczniej reagować na zmieniające się potrzeby biznesowe i warunki rynkowe.
• Jasne oddzielenie obaw :
  • DDD zachęca do wyraźnego oddzielenia problemów pomiędzy logiką domeny, problemami związanymi z infrastrukturą i problemami związanymi z interfejsem użytkownika. Izolując logikę domeny od szczegółów technicznych i problemów związanych z infrastrukturą, zespoły mogą zachować czysty i ukierunkowany model domeny, niezależny od konkretnych szczegółów implementacji lub wyborów technologicznych.
• Ulepszona testowalność :
  • Promuje wykorzystanie obiektów domeny o dobrze zdefiniowanych granicach i zachowaniach, ułatwiając pisanie lepszych i bardziej ukierunkowanych testów weryfikujących poprawność logiki domeny.
  • Projektując systemy oprogramowania z myślą o testowalności, zespoły mogą zapewnić, że zmiany w bazie kodu będą bezpieczne i przewidywalne, zmniejszając ryzyko wprowadzenia regresji lub niezamierzonych skutków ubocznych.
• Obsługa złożonych reguł biznesowych :
  • Zapewnia wzorce i techniki modelowania i wdrażania złożonych reguł biznesowych i przepływów pracy w modelu domeny.
  • Reprezentując reguły biznesowe w modelu domeny, zespoły mogą mieć pewność, że oprogramowanie dokładnie odzwierciedla zawiłości domeny biznesowej i egzekwuje ograniczenia i wymagania specyficzne dla domeny.
• Zgodność z celami biznesowymi :
  • Ostatecznie ma na celu dostosowanie wysiłków związanych z rozwojem oprogramowania do celów strategicznych i zadań firmy. Koncentrując się na zrozumieniu i modelowaniu domeny problemowej, zespoły mogą dostarczać rozwiązania programowe, które bezpośrednio wspierają cele biznesowe, stymulują innowacje i tworzą wartość dla interesariuszy i użytkowników końcowych.

Wyzwania związane z projektowaniem opartym na domenie (DDD)

• Złożoność :
  • DDD może wprowadzić złożoność, szczególnie w dużych i złożonych domenach.
  • Dokładne modelowanie skomplikowanych domen biznesowych wymaga głębokiego zrozumienia domeny i może wiązać się z radzenie sobie z niejednoznacznością i niepewnością. Skuteczne zarządzanie tą złożonością wymaga starannego planowania, współpracy i wiedzy specjalistycznej.
• Wszechobecne przyjęcie języka :
  • Ustanowienie i utrzymanie wszechobecnego języka — wspólnego słownictwa, które dokładnie reprezentuje koncepcje dziedzinowe — może być wyzwaniem. Wymaga współpracy między programistami i ekspertami domeny w celu zidentyfikowania i uzgodnienia terminów i znaczeń domeny.
  • Osiągnięcie konsensusu w sprawie wszechobecnego języka może wymagać pokonania barier komunikacyjnych i pogodzenia różnic w terminologii i perspektywach.
• Ograniczone wyrównanie kontekstu :
  • W dużych i złożonych domenach różne części domeny mogą mieć różne modele i ograniczone konteksty. Dopasowanie tych ograniczonych kontekstów i zapewnienie spójności między nimi może być wyzwaniem.
  • Wymaga jasnej komunikacji, współpracy i koordynacji między zespołami pracującymi w różnych częściach domeny, aby uniknąć niespójności i konfliktów.
• Złożoność techniczna :
  • Skuteczne wdrażanie zasad i wzorców DDD może wymagać przyjęcia nowych technologii, frameworków i podejść architektonicznych. Integracja DDD z istniejącymi systemami lub starszymi bazami kodu może być złożona i może wymagać refaktoryzacji lub przeprojektowania istniejącego kodu w celu dostosowania go do zasad DDD.
  • Aby wdrożenie DDD zakończyło się sukcesem, należy starannie uwzględnić wyzwania techniczne, takie jak wydajność, skalowalność i łatwość konserwacji.
• Odporność na zmiany :
  • Wprowadzenie DDD może napotkać opór ze strony członków zespołu, którzy są przyzwyczajeni do tradycyjnych podejść programistycznych lub którzy postrzegają DDD jako zbyt skomplikowane lub niepraktyczne.
  • Pokonanie oporu wobec zmian wymaga skutecznej komunikacji, edukacji i przywództwa, aby wykazać korzyści płynące z DDD oraz rozwiać obawy i sceptycyzm.
• Nadmierna inżynieria :
  • Istnieje ryzyko nadmiernej inżynierii podczas stosowania DDD, gdy zespoły zbytnio skupiają się na modelowaniu złożonych koncepcji dziedzinowych i wprowadzaniu niepotrzebnych abstrakcji lub złożoności. Znalezienie właściwej równowagi pomiędzy prostotą a wyrazistością ma kluczowe znaczenie, aby uniknąć nadmiernego komplikowania projektu i wdrożenia.

Przypadki użycia projektowania opartego na domenie (DDD)

• Finanse i Bankowość :
  • W sektorze finansowym DDD można wykorzystać do modelowania złożonych instrumentów finansowych, transakcji i wymogów regulacyjnych. Dokładnie przedstawiając pojęcia dziedzin, takie jak konta, transakcje i portfele, DDD pomaga zapewnić integralność i spójność systemów finansowych. Umożliwia także lepsze zarządzanie ryzykiem, przestrzeganie przepisów i raportowanie.
• Handel elektroniczny i handel detaliczny :
  • Platformy handlu elektronicznego często zajmują się złożonymi koncepcjami domenowymi, takimi jak katalogi produktów, zarządzanie zapasami, ceny i zamówienia klientów. DDD może pomóc w skutecznym modelowaniu tych koncepcji, udostępniając funkcje takie jak spersonalizowane rekomendacje, dynamiczne ceny i usprawnione przetwarzanie zamówień.
• Opieka zdrowotna i nauki o życiu :
  • W opiece zdrowotnej DDD można używać do modelowania dokumentacji pacjentów, diagnoz medycznych, planów leczenia i przepływów pracy w opiece zdrowotnej. Dokładnie przedstawiając pojęcia dziedzinowe, takie jak dane demograficzne pacjentów, historie medyczne i protokoły kliniczne, DDD umożliwia rozwój solidnych systemów elektronicznej dokumentacji medycznej (EHR), platform obrazowania medycznego i aplikacji telemedycznych.
• Ubezpieczenie :
  • Firmy ubezpieczeniowe zarządzają różnorodnymi produktami, polisami, roszczeniami i procesami ubezpieczeniowymi. DDD może pomóc w modelowaniu tych złożonych koncepcji dziedzin, udostępniając funkcje takie jak zarządzanie polisami, rozpatrywanie roszczeń, ocena ryzyka i analiza aktuarialna.
• Zarządzanie nieruchomościami i nieruchomościami :
  • Zarządzanie nieruchomościami obejmuje obsługę różnorodnych nieruchomości, umów najmu, najemców, zleceń konserwacyjnych i transakcji finansowych. DDD może pomóc w skutecznym modelowaniu koncepcji domen, udostępniając takie funkcje, jak wykazy nieruchomości, zarządzanie najmami, portale najemców i śledzenie aktywów.

Rzeczywisty przykład projektowania opartego na domenie (DDD)

Oświadczenie o problemie

Powiedzmy, że pracujemy nad aplikacją do transportu osób o nazwie RideX. System pozwala użytkownikom zamawiać przejazdy, kierowcom akceptować zlecenia przejazdów, a także ułatwia koordynację przejazdów pomiędzy użytkownikami i kierowcami.

przykładowy kod Java

Wszechobecny język

1. Użytkownik : Dotyczy osób zamawiających przejazdy za pośrednictwem platformy RideX.
2. Kierowca : odnosi się do osób, które zapewniają przejazdy użytkownikom za pośrednictwem platformy RideX.
3. Zapytanie o przejazd : reprezentuje prośbę użytkownika o przejazd, określając szczegóły, takie jak miejsce odbioru, miejsce docelowe i preferencje dotyczące przejazdu.
4. Jeździć : reprezentuje pojedynczą instancję przejazdu, łącznie ze szczegółami, takimi jak miejsca odbioru i dowozu, opłata i czas trwania.
5. Stan jazdy : reprezentuje bieżący stan przejazdu, taki jak Zażądano, Zaakceptowano, W toku lub Ukończono.

Ograniczone konteksty

1. Kontekst zarządzania przejazdami : Odpowiedzialny za zarządzanie cyklem życia przejazdów, w tym żądania przejazdów, przydzielanie przejazdów kierowcom i aktualizacje statusu przejazdów.
2. Kontekst zarządzania użytkownikami : obsługuje uwierzytelnianie użytkownika, rejestrację i funkcje specyficzne dla użytkownika, takie jak historia przejazdów i metody płatności.
3. Kontekst zarządzania sterownikami : zarządza uwierzytelnianiem kierowców, rejestracją, stanem dostępności i funkcjami specyficznymi dla kierowcy, takimi jak zarobki i oceny.

Podmioty i obiekty wartości

1. Jednostka użytkownika : reprezentuje zarejestrowanego użytkownika platformy RideX z właściwościami takimi jak identyfikator użytkownika, adres e-mail, hasło i informacje o płatności.
2. Jednostka kierowcy : reprezentuje zarejestrowanego kierowcę na platformie RideX, z właściwościami takimi jak identyfikator kierowcy, szczegóły pojazdu i status kierowcy.
3. Jednostka żądania przejazdu : reprezentuje prośbę użytkownika o przejazd, w tym właściwości takie jak identyfikator żądania, miejsce odbioru, miejsce docelowe i preferencje dotyczące przejazdu.
4. Jednostka jazdy : reprezentuje pojedynczą instancję przejazdu, w tym właściwości takie jak identyfikator przejazdu, miejsca odbioru i dowozu, opłata i status przejazdu.
5. Obiekt wartości lokalizacji : reprezentuje położenie geograficzne z właściwościami takimi jak szerokość i długość geograficzna.

Agregaty

1. Agregat jeździecki : Składa się z encji przejazdu będącej zbiorczym źródłem, wraz z powiązanymi encjami, takimi jak encja przejazdu, użytkownik i kierowca. Ride Aggregate zawiera logikę zarządzania cyklem życia przejazdu, w tym obsługę żądań przejazdu, przypisywanie kierowców i aktualizację statusu przejazdu.

Magazyn

1. Repozytorium jazdy : Zapewnia metody odpytywania i przechowywania obiektów związanych z przejazdami, takie jak pobieranie szczegółów przejazdu, aktualizowanie statusu przejazdu i przechowywanie danych związanych z przejazdem w bazie danych.

Usługi

1. Usługa przydzielania przejazdów : Odpowiedzialny za przydzielanie dostępnych kierowców do zleceń przejazdu na podstawie takich czynników, jak dostępność kierowców, bliskość miejsca odbioru i preferencje użytkownika.
2. Usługa płatności : Obsługuje przetwarzanie płatności za ukończone przejazdy, obliczanie opłat, przetwarzanie płatności oraz aktualizację informacji o płatnościach użytkowników i kierowców.

Wydarzenia domeny

1. Zdarzenie RideRequested : reprezentuje zdarzenie wyzwalane, gdy użytkownik zażąda przejazdu, zawierające takie informacje, jak szczegóły żądania przejazdu i identyfikator użytkownika.
2. Wydarzenie RideAccepted : reprezentuje zdarzenie wyzwalane, gdy kierowca zaakceptuje zlecenie przejazdu, zawierające takie informacje, jak identyfikator przejazdu, identyfikator kierowcy i miejsce odbioru.

Przykładowy scenariusz

1. Użytkownik zamawiający przejazd : użytkownik zamawia przejazd, podając miejsce odbioru, cel podróży i preferencje dotyczące przejazdu. RideX tworzy nową jednostkę żądania przejazdu i wyzwala zdarzenie RideRequestedEvent.
2. Kierowca zgadzający się na przejazd : Kierowca akceptuje zlecenie przejazdu z platformy RideX. RideX aktualizuje status przejazdu na Zaakceptowany, przypisuje kierowcę do przejazdu i wyzwala zdarzenie RideAcceptedEvent.
3. Jazda w toku : Użytkownik i kierowca koordynują przejazd, a status przejazdu zmienia się z Zaakceptowano na W toku, gdy kierowca dotrze do miejsca odbioru.
4. Zakończenie jazdy : Po dotarciu do celu status przejazdu zostaje zaktualizowany na Ukończony. RideX oblicza opłatę, przetwarza płatność i odpowiednio aktualizuje informacje dotyczące płatności użytkownika i kierowcy.