Domain-driven design (harvemmin domain-driven design , DDD) on joukko periaatteita ja järjestelmiä, joiden tarkoituksena on luoda optimaalisia objektijärjestelmiä. Se tiivistyy ohjelmistoabstrahojen luomiseen, joita kutsutaan verkkoaluemalleiksi . Näissä malleissa on liiketoimintalogiikka , joka muodostaa yhteyden tuotteen sovellusalueen todellisten olosuhteiden ja koodin välille.
Domain-Driven Design ei ole tietty tekniikka tai menetelmä. DDD on joukko sääntöjä, joiden avulla voit tehdä oikeat suunnittelupäätökset. Tämän lähestymistavan avulla voit nopeuttaa huomattavasti ohjelmistosuunnitteluprosessia tuntemattomalla aihealueella.
DDD-lähestymistapa on erityisen hyödyllinen tilanteissa, joissa kehittäjä ei ole asiantuntija kehitettävän tuotteen alueella. Esimerkiksi: ohjelmoija ei voi tietää kaikkia alueita, joille ohjelmistoja pitää luoda , mutta rakenteen oikealla esityksellä, toimialuelähtöisellä lähestymistavalla, hän voi helposti suunnitella sovelluksen avainkohtien ja työalueen tuntemuksen perusteella. .
Tämän termin esitteli ensimmäisenä E. Evans samannimisessä kirjassaan "Domain-Driven Design" [1] .
Ihannetapauksessa suunnittelussa halutaan yksi malli, joka kuvaa täysin koko aihealueen, mutta todellisuudessa tuotekehitysprosessin yksinkertaistamiseksi toimialue esitetään useiden toisiinsa liittyvien mallien yhdistelmänä.
Sovellusarkkitehtuurikaavio on kuvaus yhdestä tai useammasta toimialuemallista ja niiden suhteista toisiinsa.
Useiden mallien käyttö projektin eri tasoilla . Tätä lähestymistapaa käytetään erilaisten mallien välisten suhteiden vähentämiseen, mikä eliminoi koodin monimutkaisuuden ja monimutkaisuuden . Joskus ei ole selvää, missä yhteydessä mallia tulisi käyttää.
Ratkaisu: Määritä tarkalleen konteksti, jossa mallia käytetään. Määritä tämän mallin ja sen ominaisuuksien käytön rajat.
Kun suuri määrä ihmisiä työskentelee projektin parissa, mallilla on taipumus jakaa useisiin pienempiin osiin. Mitä enemmän ihmisiä, sitä tärkeämpi tämä ongelma. Lopulta hankkeen eheys menetetään.
Ratkaisu: Yhdistele jatkuvasti eri kehittäjien koodinpätkiä ja tarkista toimivuus testaamalla . Tämä antaa kaikille kehittäjille mahdollisuuden pysyä yhdessä suuressa konseptissa.
Kun työskennellään useiden eri mallien parissa suuressa ryhmässä, eri tiimin jäsenet eivät välttämättä ole tietoisia muiden mallien kokonaisuuksista, mikä vaikeuttaa lopputuotteen kokoamisprosessia.
Ratkaisu: Määritä suunnitteluvaiheessa tarkasti, mitä kukin malli tekee ja miten se liittyy muihin malleihin. Lopulta sinun pitäisi saada mallisuhdekartta.
Kun suunnitellaan toimialuelähtöiseen lähestymistapaan, käytetään seuraavia käsitteitä:
Useimmat yritysten järjestelmät käyttävät laajamittaisia vastuualueita. DDD:ssä tätä korkeinta organisaatiotasoa kutsutaan rajoitetuksi kontekstiksi. Esimerkiksi suuren teleyrityksen laskutusjärjestelmässä voi olla seuraavat avainelementit:
Kaikki edellä mainitut elementit on sisällytettävä yhteen, keskeytymättömään järjestelmään. Suunnittelussa ilmoitusjärjestelmä ja turvajärjestelmä erottuvat täysin eri asioista. Järjestelmät, joissa toteutus ei onnistu erottamaan ja eristämään rajattuja yhteyksiä, saavat usein arkkitehtonisen tyylin , jonka Brian Foot ja Joseph Yoder antoivat vuonna 1999 osuvasti nimen " Big Mudball ". [2]
Aluekohtaisen suunnittelun ydin on kontekstien spesifinen määrittely ja mallinnuksen rajoittaminen niissä.
Helpoin tapa ilmaista entiteettiä on substantiivit : ihmiset, paikat, tuotteet jne. Entiteeteillä on sekä persoonallisuus että elinkaarensa. Suunnitteluhetkellä kokonaisuuksia tulisi ajatella käyttäytymisyksiköinä eikä datayksiköinä. Useimmiten jokin toiminto, jota yrität lisätä malliin, on vastaanotettava jonkin entiteetin toimesta tai uuden entiteetin luominen tai nouto alkaa. Löyhämmin kytketystä koodista löytyy paljon apu- tai ohjausluokkia , jotka tarkistavat entiteettejä ulkopuolelta.
Arvoobjekti on ominaisuus, joka on tärkeä mallinnettavalla toimialueella . Niillä, toisin kuin entiteetillä, ei ole nimitystä; ne kuvaavat vain konkreettisia kokonaisuuksia, joilla on jo nimitykset. Arvoobjektien hyödyllisyys on, että ne kuvaavat entiteettien ominaisuuksia paljon tyylikkäämmin ja tarkoituksenmukaisemmin. Aina kannattaa muistaa, että objektin arvo ei koskaan muutu koko ohjelmakoodin suorituksen aikana . Kun se on luotu, muutoksia ei voi tehdä.
Aggregaatti on erityinen kokonaisuus, johon kuluttajat pääsevät suoraan. Aggregaattien käytön avulla voit välttää mallin muodostavien objektien liiallisen yhteyden. Tämä välttää sekaannukset ja yksinkertaistaa rakennetta, koska se ei salli tiiviisti kytkettyjen järjestelmien luomista.
Joskus toimialueella on toimintoja tai prosesseja , joilla ei ole nimeä tai elinkaarta. Domain-palvelut tarjoavat työkalun näiden käsitteiden mallintamiseen. Ne ovat valtiottomia ja erittäin kytkettyjä, ja ne tarjoavat usein yhden julkisen menetelmän ja joskus ylikuormituksen joukkotoimintoihin. Jos käyttäytymiseen sisältyy useita riippuvuuksia, eikä entiteetistä löydy sopivaa paikkaa kyseisen toiminnan isännöimiseksi, käytetään palvelua. Vaikka itse termi "palvelu" on kehitysmaailmassa ylikuormitettu erilaisilla merkityksillä, mutta tässä aiheessa se tarkoittaa pientä luokkaa , joka ei edusta tiettyä henkilöä, paikkaa tai asiaa suunniteltavassa sovelluksessa, vaan sisältää jonkinlaisia prosesseja. . Palvelujen käytön avulla voit siirtyä monikerroksiseen arkkitehtuuriin sekä integroida useita malleja, mikä aiheuttaa riippuvuuden infrastruktuurista. [3]
Vaikka konseptissa domain-orientoitunutta suunnittelua ei pitäisi rajoittua mihinkään esityksiin, mutta käytännössä olio-ohjelmoinnin vahvuuksia hyödynnetään . Tämä on perinnön , kapseloinnin , edustuksen käyttöä menetelminä ja luokkina. On muistettava, että verkkoaluekohtaista lähestymistapaa voidaan soveltaa OOP-kielten, kuten Java , C# tai C++ , lisäksi myös toiminnallisiin kieliin, kuten F# , Erlang . Erityisen hyödyllisiä ovat kielet, jotka tukevat omien verkkotunnuskohtaisten kielensä luomista ja käyttöä , kuten Scala (katso myös LOP ).
| Ohjelmistokehitys | |
|---|---|
| Prosessi | |
| Korkean tason käsitteet | |
| Ohjeet |
|
| Kehittämismenetelmät _ | |
| Mallit |
|
| Merkittäviä lukuja |
|