Domain-Driven Design (DDD) on lähestymistapa ohjelmistokehitykseen, joka keskittyy ymmärtämään ja mallintamaan ongelma-aluetta, jossa ohjelmistojärjestelmä toimii. Se korostaa tiiviin yhteistyön tärkeyttä toimialueen asiantuntijoiden kanssa, jotta voidaan kehittää syvällinen ymmärrys verkkotunnuksen monimutkaisuudesta ja monimutkaisuudesta. DDD tarjoaa joukon periaatteita, malleja ja käytäntöjä, joiden avulla kehittäjät voivat tehokkaasti kaapata ja ilmaista toimialuekonsepteja ohjelmistosuunnitelmissaan.

tehdä skriptistä suoritettavaa

Tärkeitä aiheita verkkotunnuslähtöiselle suunnittelulle (DDD)

• Mitä on Domain-Driven Design (DDD)?
• Verkkotunnuksen tuntemuksen merkitys
• Strateginen suunnittelu toimialuelähtöisessä suunnittelussa (DDD)
• Taktiset suunnittelumallit Domain-Driven Designissa (DDD)
• Verkkotunnuslähtöisen suunnittelun (DDD) edut
• Domain-Driven Designin (DDD) haasteet
• Domain-Driven Designin (DDD) käyttötapaukset
• Tosimaailman esimerkki verkkotunnuslähtöisestä suunnittelusta (DDD)

Mitä on Domain-Driven Design (DDD)?

Verkkotunnus

Se viittaa aihealueeseen tai ongelma-alueeseen, jota ohjelmistojärjestelmää rakennetaan käsittelemään. Se kattaa reaalimaailman käsitteet, säännöt ja prosessit, joita ohjelmiston on tarkoitus mallintaa tai tukea. Esimerkiksi pankkisovelluksessa toimialue sisältää käsitteitä, kuten tilit, tapahtumat, asiakkaat ja pankkitoimintaan liittyvät määräykset.

Ajettu

Ohjattu tarkoittaa, että ohjelmistojärjestelmän suunnittelua ohjaavat tai vaikuttavat toimialueen ominaisuudet ja vaatimukset. Toisin sanoen suunnittelupäätökset perustuvat alueen syvään ymmärrykseen sen sijaan, että ne perustuisivat pelkästään teknisiin näkökohtiin tai toteutusyksityiskohtiin.

Design

Suunnittelulla tarkoitetaan ohjelmistojärjestelmän suunnitelman tai suunnitelman luomisprosessia. Tämä sisältää päätökset siitä, miten järjestelmä rakennetaan, miten eri komponentit toimivat vuorovaikutuksessa ja miten järjestelmä täyttää sen toimiva ja ei-toiminnallinen vaatimukset. Domain-Driven Designin yhteydessä painopiste on ohjelmiston suunnittelussa tavalla, joka kuvastaa tarkasti toimialueen rakennetta ja käyttäytymistä.

Domain-Driven Design on ohjelmoijan esittelemä konsepti Eric Evans kirjassaan vuonna 2004 Verkkotunnuslähtöinen suunnittelu: Ohjelmiston monimutkaisuuden poistaminen

Verkkotunnuksen tuntemuksen merkitys

Oletetaan, että olemme suunnitelleet ohjelmistoja käyttämällä viimeisintä teknologiaa ja infrastruktuuria, ja ohjelmistosuunnitteluarkkitehtuurimme on hämmästyttävä, mutta kun julkaisemme tämän ohjelmiston markkinoille, loppukäyttäjä päättää, onko järjestelmämme loistava vai ei. Myös jos järjestelmä ei ratkaise liiketoiminnan tarpeita, ei siitä ole kenellekään hyötyä. Ei ole väliä kuinka kauniilta se näyttää tai kuinka hyvä arkkitehtuuri sen infrastruktuuri on.

Mukaan Eric Evans , Ohjelmistoja kehittäessämme ei keskitytä ensisijaisesti teknologiaan, vaan ensisijaisesti liiketoimintaan. Muistaa,

Asiakkaan tehtävä ei ole tietää, mitä hän haluaa – Steve Jobs

kuinka tehdä uusiksi Photoshopissa

Strateginen suunnittelu toimialuelähtöisessä suunnittelussa (DDD)

Strategic Design in Domain-Driven Design (DDD) keskittyy ohjelmistojärjestelmän kokonaisarkkitehtuurin ja rakenteen määrittelemiseen tavalla, joka vastaa ongelma-aluetta. Se käsittelee korkean tason huolenaiheita, kuten verkkotunnuskonseptien järjestämistä, järjestelmän osiointia hallittaviin osiin ja selkeän rajan luomiseen eri komponenttien välille.

Katsotaanpa joitain verkkotunnuslähtöisen suunnittelun (DDD) strategisen suunnittelun avainkäsitteitä.

1. Rajalliset kontekstit

• Rajoitettu konteksti edustaa tiettyä aluetta yleisellä ongelmaalueella, jossa tietty malli tai kieli soveltuu johdonmukaisesti.
• Järjestelmän eri osilla voi olla eri merkitys samoilla termeillä, ja rajattu konteksti määrittelee selkeät rajat, joiden sisällä näillä termeillä on erityisiä merkityksiä.
• Näin tiimit voivat kehittää malleja, jotka on räätälöity tiettyihin konteksteihin aiheuttamatta sekaannusta tai epäjohdonmukaisuuksia.
• Rajoitetut kontekstit auttavat hallitsemaan monimutkaisuutta jakamalla suuren, monimutkaisen toimialueen pienempiin, paremmin hallittaviin osiin.

2. Kontekstin kartoitus

• Kontekstin kartoitus on prosessi, jossa määritellään suhteet ja vuorovaikutukset eri rajattujen kontekstien välillä.
• Se sisältää päällekkäisten tai integroituneiden alueiden tunnistamisen kontekstien välillä ja viestintäkanavien ja sopimusten luomisen niiden välille.
• Kontekstikartoitus auttaa varmistamaan, että järjestelmän eri osat voivat tehdä yhteistyötä tehokkaasti säilyttäen silti selkeät rajat niiden välillä.
• Kontekstin kartoitukseen on olemassa erilaisia ​​malleja ja tekniikoita, kuten kumppanuus, jaettu ydin ja asiakas-toimittaja.

3. Strategiset mallit

• Strategiset mallit ovat yleisiä ohjeita tai periaatteita ohjelmistojärjestelmän arkkitehtuurin järjestämiseksi tavalla, joka on linjassa ongelmaalueen kanssa.
• Nämä mallit auttavat vastaamaan yleisiin haasteisiin monimutkaisten järjestelmien suunnittelussa ja tarjoavat todistettuja lähestymistapoja järjestelmän tehokkaaseen jäsentämiseen.
• Esimerkkejä strategisista malleista ovat aggregaatit, verkkotunnuksen tapahtumat ja korruptiontorjuntakerros.
• Nämä mallit tarjoavat ratkaisuja toistuviin ongelmiin toimialuelähtöisessä suunnittelussa ja auttavat varmistamaan, että järjestelmän arkkitehtuuri heijastaa tarkasti taustalla olevia toimialuekonsepteja.

4. Jaettu ydin

• Jaettu ydin on strateginen malli, jossa tunnistetaan yhteisiä alueita eri rajattujen kontekstien välillä ja luodaan toimialuemallin jaettu osajoukko, jota useat kontekstit käyttävät.
• Tämä jaettu osajoukko tai ydin auttaa helpottamaan kontekstien välistä yhteistyötä ja integrointia samalla kun kukin konteksti voi säilyttää oman erillisen mallinsa.
• Jaettua ydintä tulee käyttää harkiten, koska se aiheuttaa riippuvuuksia kontekstien välillä ja voi johtaa kytkeytymiseen, jos sitä ei hallita huolellisesti.

5. Anti-Corruption Layer (ACL)

• Korruptionvastainen kerros on toinen strateginen malli, joka auttaa suojaamaan järjestelmää ulkoisten tai vanhojen järjestelmien vaikutukselta, jotka käyttävät eri malleja tai kieliä.
• ACL toimii käännöskerroksena ulkoisen järjestelmän ja ydinverkkoalueen mallin välillä muuntaen tietoja ja viestejä tarpeen mukaan yhteensopivuuden varmistamiseksi.
• Tämä mahdollistaa sen, että ydinverkkoaluemalli pysyy puhtaana ja keskittyy ongelma-alueeseen, samalla kun se integroituu tarvittaessa ulkoisiin järjestelmiin.

6. Jokapaikan kieli

Ubiquitous Language tarkoittaa jaettua sanastoa tai kieltä, jota käytetään johdonmukaisesti ja yleismaailmallisesti kaikissa ohjelmistojärjestelmän kehittämiseen osallistuvissa sidosryhmissä. Tämä kieli koostuu termeistä, lauseista ja käsitteistä, jotka edustavat tarkasti toimialueen tietoa ja käsitteitä.

Joitakin kaikkialla esiintyvän kielen keskeisiä periaatteita ovat:

• Jaettu ymmärrys : Ubiquitous Languagen ensisijainen tavoite on luoda yhteinen ymmärrys ongelma-alueesta kaikille kehitystiimin jäsenille, mukaan lukien kehittäjät, toimialueen asiantuntijat, yritysanalyytikot ja sidosryhmät. Käyttämällä yhteistä kieltä kaikki osapuolet voivat kommunikoida tehokkaammin ja tarkemmin välittää toimialueen käsitteitä ja vaatimuksia.
• Johdonmukaisuus ja selkeys : Ubiquitous Language edistää viestinnän johdonmukaisuutta ja selkeyttä käyttämällä tarkkaa ja yksiselitteistä terminologiaa. Jokaisella kielen termillä tai lauseella tulee olla selkeä ja sovittu merkitys,
• Yhdenmukaisuus liiketoimintakonseptien kanssa : DDD:ssä käytetyn kielen tulee vastata liiketoiminta-alueella käytettyä terminologiaa ja käsitteitä. Sen tulisi heijastaa tapaa, jolla toimialueen asiantuntijat ajattelevat ja puhuvat ongelmaalueesta, varmistaen, että ohjelmisto edustaa tarkasti todellisia käsitteitä ja prosesseja.
• Evolutionaarinen luonto : Ubiquitous Language ei ole staattista, vaan kehittyy ajan myötä, kun tiimi saa syvemmän ymmärryksen toimialueesta ja vaatimusten muuttuessa. Sen tulisi mukautua vastaamaan uusia oivalluksia, löytöjä tai liiketoiminnan prioriteettien muutoksia ja varmistaa, että kieli pysyy relevanttina ja ajan tasalla koko kehitysprosessin ajan.

Taktiset suunnittelumallit Domain-Driven Designissa (DDD)

Domain-Driven Designissa (DDD) taktiset suunnittelumallit ovat erityisiä strategioita tai tekniikoita, joita käytetään toimialuemallin jäsentämiseen ja järjestämiseen ohjelmistojärjestelmässä. Nämä mallit auttavat kehittäjiä vangitsemaan tehokkaasti toimialueen monimutkaisuuden ja edistävät samalla ylläpidettävyyttä, joustavuutta ja skaalautuvuutta.

Katsotaanpa joitain DDD:n tärkeimpiä taktisia suunnittelumalleja:

1. Entiteetti

Entiteetti on toimialueobjekti, jolla on erillinen identiteetti ja elinkaari. Entiteeteille on tunnusomaista niiden yksilölliset tunnisteet ja muuttuva tila. Ne kapseloivat toimialueen tiettyyn konseptiin liittyvän käyttäytymisen ja datan.

Esimerkiksi pankkisovelluksessa aBankAccount>entiteetillä voi olla ominaisuuksia, kuten tilinumero, saldo ja omistaja, sekä tapoja tallettaa, nostaa tai siirtää varoja.

2. Arvoobjekti

Arvoobjekti on toimialueen objekti, joka edustaa käsitteellisesti muuttumatonta arvoa. Toisin kuin entiteetit, arvoobjekteilla ei ole erillistä identiteettiä, ja niitä käytetään yleensä edustamaan entiteettien attribuutteja tai ominaisuuksia. Arvoobjektit ovat tasavertaisia ​​ominaisuuksiensa perusteella, eivät identiteettinsä perusteella.

Esimerkiksi aMoney>arvoobjekti voi edustaa tiettyä valuutan määrää, ja se sisältää ominaisuuksia, kuten valuutan tyypin ja summan.

3. Aggregaatti

• Aggregaatti on klusteri toimialueobjekteja, joita käsitellään yhtenä yksikkönä tietojen johdonmukaisuuden ja tapahtumien eheyden varmistamiseksi.
• Aggregaatit koostuvat yhdestä tai useammasta entiteetistä ja arvoobjektista, joista yksi on määritetty aggregaatin juureksi.
• Aggregaatin juuri toimii sisääntulopisteenä aggregaatin sisäiseen tilaan pääsemiseksi ja muokkaamiseksi.
• Aggregaatit pakottavat johdonmukaisuusrajat toimialuemallin sisällä varmistaen, että muutokset liittyviin objekteihin tehdään atomaarisesti.

Esimerkiksi verkkokauppajärjestelmässä anOrder>aggregaatti voi koostua kokonaisuuksista, kutenOrderItem>jaCustomer>, kanssaOrder>kokonaisuutena toimiva kokonaisuus.

4. Arkisto

• Arkisto on mekanismi tietojen pääsyn ja pysyvyyslogiikan poistamiseksi toimialuemallista.
• Tietovarastot tarjoavat standardoidun käyttöliittymän verkkoalueen objektien kyselyyn ja tallentamiseen, piilottaen tiedot siitä, kuinka tietoja haetaan tai tallennetaan. Tietovarastot kapseloivat logiikan toimialueobjektien ja taustalla olevien tiedontallennusmekanismien, kuten tietokantojen tai ulkoisten palvelujen, välillä.
• Kun verkkotunnusmalli irrotetaan tietojen käyttöongelmista, arkistot mahdollistavat suuremman joustavuuden ja ylläpidettävyyden.

Esimerkiksi aCustomerRepository>saattaa tarjota menetelmiä kyselyyn ja tallentamiseenCustomer>kokonaisuuksia.

5. Tehdas

• Tehdas on a luova malli käytetään kapseloimaan logiikka monimutkaisten toimialueen objektien esiintymien luomiseen. Tehtaat abstraktioivat objektien ilmentämisprosessin, jolloin asiakkaat voivat luoda objekteja ilman, että heidän tarvitsee tietää niiden rakentamisen yksityiskohtia.
• Tehtaat ovat erityisen hyödyllisiä luotaessa objekteja, jotka vaativat monimutkaista alustuslogiikkaa tai sisältävät useita vaiheita.

Esimerkiksi aProductFactory>saattaa olla vastuussa esiintymien luomisestaProduct>entiteetit oletuskokoonpanoilla.

6. Palvelu

• Palvelu on toimialueobjekti, joka edustaa käyttäytymistä tai toimintaa, joka ei luonnollisesti kuulu mihinkään tiettyyn kokonaisuuteen tai arvoobjektiin.
• Palvelut kapseloivat toimialueen logiikan, joka toimii useissa objekteissa tai organisoi objektien välisiä vuorovaikutuksia.
• Palvelut ovat yleensä tilattomia ja keskittyvät tiettyjen tehtävien suorittamiseen tai toimialueen sääntöjen täytäntöönpanoon.

Esimerkiksi anOrderService>saattaa tarjota menetelmiä tilausten käsittelyyn, alennusten soveltamiseen ja toimituskulujen laskemiseen.

Verkkotunnuslähtöisen suunnittelun (DDD) edut

• Jaettu ymmärrys :
  • Se rohkaisee yhteistyötä toimialueen asiantuntijoiden, kehittäjien ja sidosryhmien välillä.
  • Rohkaisemalla yhteistä ymmärrystä ongelma-alueesta kaikkialla esiintyvän kielen avulla tiimit voivat kommunikoida tehokkaammin ja varmistaa, että ohjelmisto vastaa tarkasti yrityksen tarpeita ja vaatimuksia.
• Keskity ydinverkkotunnukseen :
  • Se auttaa tiimejä tunnistamaan ja priorisoimaan sovelluksen ydinalueet – järjestelmän alueet, jotka tuottavat eniten arvoa yritykselle. Keskittämällä kehitystyön ydinalueelle tiimit voivat tarjota toimintoja, jotka vastaavat suoraan liiketoimintatavoitteisiin ja erottavat ohjelmiston kilpailijoista.
• Muutoksen sietokyky :
  • Siinä painotetaan muutosten kestävien ohjelmistojärjestelmien suunnittelua mallintamalla toimialue tavalla, joka heijastaa ongelmaalueen luontaista monimutkaisuutta ja epävarmuutta.
  • Ottamalla muutoksen luonnolliseksi osaksi ohjelmistokehitystä tiimit voivat vastata tehokkaammin muuttuviin liiketoiminnan tarpeisiin ja markkinaolosuhteisiin.
• Selkeä huolenaiheiden erottelu :
  • DDD kannustaa erottamaan selkeästi toimialuelogiikan, infrastruktuurin ja käyttöliittymän ongelmat. Eristämällä verkkotunnuksen logiikan teknisistä yksityiskohdista ja infrastruktuuriongelmista tiimit voivat ylläpitää puhdasta ja kohdennettua toimialuemallia, joka on riippumaton erityisistä toteutuksen yksityiskohdista tai teknisistä valinnoista.
• Parannettu testattavuus :
  • Se edistää verkkotunnusobjektien käyttöä, joilla on hyvin määritellyt rajat ja käyttäytyminen, mikä helpottaa parempien ja kohdistettujen testien kirjoittamista, jotka varmistavat toimialueen logiikan oikeellisuuden.
  • Suunnittelemalla ohjelmistojärjestelmiä testattavuutta silmällä pitäen tiimit voivat varmistaa, että koodikannan muutokset ovat turvallisia ja ennustettavia, mikä vähentää regressioiden tai tahattomien sivuvaikutusten riskiä.
• Tuki monimutkaisille liiketoimintasäännöille :
  • Se tarjoaa malleja ja tekniikoita monimutkaisten liiketoimintasääntöjen ja työnkulkujen mallintamiseen ja toteuttamiseen toimialuemallissa.
  • Esittämällä liiketoimintasäännöt nimenomaisesti toimialuemallissa tiimit voivat varmistaa, että ohjelmisto heijastaa tarkasti liiketoiminta-alueen monimutkaisuutta ja pakottaa toimialuekohtaiset rajoitukset ja vaatimukset.
• Yhdenmukaisuus liiketoimintatavoitteiden kanssa :
  • Viime kädessä se pyrkii linjaamaan ohjelmistokehitystyöt liiketoiminnan strategisten tavoitteiden ja tavoitteiden kanssa. Keskittymällä ongelmaalueen ymmärtämiseen ja mallintamiseen, tiimit voivat toimittaa ohjelmistoratkaisuja, jotka tukevat suoraan liiketoiminnan tavoitteita, edistävät innovaatioita ja luovat lisäarvoa sidosryhmille ja loppukäyttäjille.

Domain-Driven Designin (DDD) haasteet

• Monimutkaisuus :
  • DDD voi aiheuttaa monimutkaisuutta, erityisesti suurilla ja monimutkaisilla aloilla.
  • Monimutkaisten liiketoiminta-alueiden tarkka mallintaminen edellyttää alueen syvällistä ymmärtämistä, ja siihen voi liittyä epäselvyyden ja epävarmuuden käsittelemistä. Tämän monimutkaisuuden tehokas hallinta vaatii huolellista suunnittelua, yhteistyötä ja asiantuntemusta.
• Jokapaikan kielen omaksuminen :
  • Arjen kielen – jaetun sanaston, joka edustaa tarkasti toimialueen käsitteitä – luominen ja ylläpitäminen voi olla haastavaa. Se vaatii yhteistyötä kehittäjien ja toimialueen asiantuntijoiden välillä tunnistaakseen ja sopiakseen verkkotunnuksen termeistä ja merkityksistä.
  • Yhteisymmärryksen saavuttaminen kaikkialla esiintyvästä kielestä saattaa edellyttää kommunikaatioesteiden ylittämistä ja terminologian ja näkökulmien erojen sovittamista yhteen.
• Rajoitettu kontekstin tasaus :
  • Suurilla ja monimutkaisilla aloilla toimialueen eri osilla voi olla erilliset mallit ja rajatut kontekstit. Näiden rajallisten kontekstien kohdistaminen ja niiden välisen johdonmukaisuuden varmistaminen voi olla haastavaa.
  • Se edellyttää selkeää viestintää, yhteistyötä ja koordinaatiota toimialueen eri osissa työskentelevien tiimien välillä epäjohdonmukaisuuksien ja ristiriitojen välttämiseksi.
• Tekninen monimutkaisuus :
  • DDD-periaatteiden ja -mallien tehokas toteuttaminen saattaa edellyttää uusien teknologioiden, kehysten ja arkkitehtonisten lähestymistapojen omaksumista. DDD:n integroiminen olemassa oleviin järjestelmiin tai vanhoihin koodikantoihin voi olla monimutkaista ja saattaa edellyttää olemassa olevan koodin uudelleenmuotoilua tai uudelleensuunnittelua DDD-periaatteiden mukaiseksi.
  • Teknisiä haasteita, kuten suorituskykyä, skaalautuvuutta ja ylläpidettävyyttä, on käsiteltävä huolellisesti DDD:n käyttöönoton onnistumisen varmistamiseksi.
• Muutosvastarinta :
  • DDD:n esittely saattaa kohdata vastustusta tiimin jäseniltä, ​​jotka ovat tottuneet perinteisiin kehitystapoihin tai pitävät DDD:tä liian monimutkaisena tai epäkäytännöllisenä.
  • Muutosvastuksen voittaminen edellyttää tehokasta viestintää, koulutusta ja johtajuutta, jotta voidaan osoittaa DDD:n edut ja käsitellä huolia ja skeptisyyttä.
• Ylisuunnittelu :
  • DDD:tä käytettäessä on olemassa ylisuunnittelun riski, kun tiimit keskittyvät liikaa monimutkaisten verkkotunnuskonseptien mallintamiseen ja tarpeettomien abstraktien tai monimutkaisuuden tuomiseen. Oikean tasapainon löytäminen yksinkertaisuuden ja ilmeisyyden välillä on ratkaisevan tärkeää, jotta suunnittelua ja toteutusta ei tehdä liian monimutkaiseksi.

Domain-Driven Designin (DDD) käyttötapaukset

• Rahoitus ja pankkitoiminta :
  • Rahoitusalalla DDD:tä voidaan käyttää monimutkaisten rahoitusinstrumenttien, transaktioiden ja sääntelyvaatimusten mallintamiseen. Edustamalla tarkasti verkkotunnuksen käsitteet, kuten tilit, tapahtumat ja salkut, DDD auttaa varmistamaan rahoitusjärjestelmien eheyden ja johdonmukaisuuden. Se mahdollistaa myös paremman riskienhallinnan, vaatimustenmukaisuuden ja raportoinnin.
• Verkkokauppa ja vähittäiskauppa :
  • Verkkokaupan alustat käsittelevät usein monimutkaisia ​​verkkotunnuskonsepteja, kuten tuoteluetteloita, varastonhallintaa, hinnoittelua ja asiakastilauksia. DDD voi auttaa mallintamaan näitä konsepteja tehokkaasti mahdollistaen ominaisuuksia, kuten henkilökohtaisia ​​suosituksia, dynaamista hinnoittelua ja virtaviivaista tilausten käsittelyä.
• Terveydenhuolto ja biotieteet :
  • Terveydenhuollossa DDD:tä voidaan käyttää potilastietojen, lääketieteellisten diagnoosien, hoitosuunnitelmien ja terveydenhuollon työnkulkujen mallintamiseen. Edustamalla tarkasti toimialueen käsitteitä, kuten potilaiden demografisia tietoja, sairaushistoriaa ja kliinisiä protokollia, DDD mahdollistaa kestävien sähköisten terveyskertomusjärjestelmien (EHR), lääketieteellisten kuvantamisalustojen ja telelääketieteen sovellusten kehittämisen.
• Vakuutus :
  • Vakuutusyhtiöt hallinnoivat erilaisia ​​tuotteita, vakuutuksia, korvauksia ja vakuutusprosesseja. DDD voi auttaa mallintamaan näitä monimutkaisia ​​toimialueen käsitteitä, mikä mahdollistaa toimintojen, kuten politiikanhallinnan, korvausvaatimusten käsittelyn, riskien arvioinnin ja vakuutusmatemaattisen analyysin.
• Kiinteistö- ja kiinteistönhallinta :
  • Kiinteistö- ja kiinteistöhallintaan sisältyy erilaisten kiinteistöjen, vuokrasopimusten, vuokralaisten, huoltopyyntöjen ja rahoitustapahtumien käsittelyä. DDD voi auttaa mallintamaan näitä verkkotunnuskonsepteja tehokkaasti mahdollistaen ominaisuuksia, kuten kiinteistöjen listaukset, vuokranhallinnan, vuokraportaalit ja omaisuuden seurannan.

Tosimaailman esimerkki verkkotunnuslähtöisestä suunnittelusta (DDD)

Ongelmailmoitus

Oletetaan, että kehitämme kyytipalvelusovellusta nimeltä RideX. Järjestelmän avulla käyttäjät voivat pyytää kyytiä, kuljettajat hyväksyä kyytipyynnöt ja helpottaa ajojen koordinointia käyttäjien ja kuljettajien välillä.

java synkronointi

Jokapaikan kieli

1. Käyttäjä : Viittaa henkilöihin, jotka pyytävät kyytiä RideX-alustan kautta.
2. Kuljettaja : Viittaa henkilöihin, jotka tarjoavat käyttäjille kyytiä RideX-alustan kautta.
3. Ajopyyntö : Edustaa käyttäjän kyytipyyntöä, jossa määritellään tiedot, kuten noutopaikka, määränpää ja kyytiasetukset.
4. Ratsastaa : Edustaa yhtä matkaa, mukaan lukien tiedot, kuten nouto- ja luovutuspaikat, hinta ja kesto.
5. Ajon tila : Edustaa matkan nykyistä tilaa, kuten Pyydetty, Hyväksytty, Käynnissä tai Valmis.

Rajalliset kontekstit

1. Ajonhallinnan konteksti : Vastaa ajomatkojen elinkaaren hallinnasta, mukaan lukien kyytipyynnöt, kuljettajien kyytitehtävät ja ajon tilan päivitykset.
2. Käyttäjien hallinnan konteksti : Käsittelee käyttäjän todennusta, rekisteröintiä ja käyttäjäkohtaisia ​​ominaisuuksia, kuten ajohistoriaa ja maksutapoja.
3. Ohjaimen hallinnan konteksti : Hallitsee kuljettajan todennusta, rekisteröintiä, saatavuustilaa ja kuljettajakohtaisia ​​ominaisuuksia, kuten tuloja ja luokituksia.

Entiteetit ja arvoobjektit

1. Käyttäjäkokonaisuus : Edustaa RideX-alustan rekisteröityä käyttäjää, jolla on ominaisuuksia, kuten käyttäjätunnus, sähköpostiosoite, salasana ja maksutiedot.
2. Kuljettajayksikkö : Edustaa rekisteröityä kuljettajaa RideX-alustalla ja ominaisuuksia, kuten kuljettajan tunnus, ajoneuvon tiedot ja kuljettajan tila.
3. Ajopyyntöyksikkö : Edustaa käyttäjän kyytipyyntöä, mukaan lukien ominaisuudet, kuten pyyntötunnus, noutopaikka, määränpää ja kyytiasetukset.
4. Ride Entity : Edustaa yhtä kyytiä, mukaan lukien ominaisuudet, kuten kyytitunnus, nouto- ja palautuspaikat, hinta ja kyydin tila.
5. Sijaintiarvoobjekti : Edustaa maantieteellistä sijaintia ja ominaisuuksia, kuten leveys- ja pituusaste.

Aggregaatit

1. Ajoyhdistelmä : Koostuu Ajo-entiteetistä koontijuurena sekä siihen liittyvien entiteettien, kuten kyytipyyntö-, käyttäjä- ja kuljettajakokonaisuuksien, kanssa. Ride Aggregate kiteyttää logiikan ajon elinkaaren hallintaan, mukaan lukien kyytipyyntöjen käsittely, kuljettajien määrittäminen ja ajon tilan päivitys.

Arkisto

1. Ride Repository : Tarjoaa menetelmiä kyytiin liittyvien entiteettien kyselyyn ja tallentamiseen, kuten kyytitietojen hakemiseen, kyydin tilan päivittämiseen ja kyytiin liittyvien tietojen tallentamiseen tietokantaan.

Palvelut

1. Ratsastuspalvelu : Vastaa käytettävissä olevien kuljettajien määrittämisestä kyytipyyntöihin perustuen esimerkiksi kuljettajan saatavuuteen, noutopaikan läheisyyteen ja käyttäjän mieltymyksiin.
2. Maksupalvelu : Käsittelee suoritettujen matkojen maksujen käsittelyä, laskee hintoja, käsittelee maksuja sekä päivittää käyttäjän ja kuljettajan maksutietoja.

Verkkotunnuksen tapahtumat

1. RideRequestedEvent : Edustaa tapahtumaa, joka laukeaa, kun käyttäjä pyytää kyytiä ja sisältää tietoja, kuten kyytipyynnön tiedot ja käyttäjätunnuksen.
2. RideAcceptedEvent : Edustaa tapahtumaa, joka laukeaa, kun kuljettaja hyväksyy kyytipyynnön ja sisältää tietoja, kuten kyytitunnuksen, kuljettajan tunnuksen ja noutopaikan.

Esimerkki skenaario

1. Käyttäjä pyytää kyytiä : Käyttäjä pyytää kyytiä antamalla noutopaikan, määränpään ja kyytiasetukset. RideX luo uuden kyytipyyntöolion ja laukaisee RideRequestedEvent-tapahtuman.
2. Kuljettaja hyväksyy kyydin : Kuljettaja hyväksyy kyytipyynnön RideX-alustalta. RideX päivittää ajon tilan Hyväksytyksi, määrittää kuljettajan kyytiin ja laukaisee RideAcceptedEvent-tapahtuman.
3. Ajo käynnissä : Käyttäjä ja kuljettaja koordinoivat matkaa, ja ajon tila siirtyy Hyväksytty-tilasta Käynnissä-tilaan, kun kuljettaja saavuttaa noutopaikan.
4. Ajon valmistuminen : Kun olet saavuttanut määränpään, ajon tilaksi päivitetään Valmis. RideX laskee hinnan, käsittelee maksun ja päivittää käyttäjän ja kuljettajan maksutiedot vastaavasti.