kanoninen tietomalli määritellään Yritysintegraatiomalleissa ratkaisuksi riippuvuuksien minimoimiseksi integroitaessa eri tietomuotoja käyttäviä sovelluksia. Toisin sanoen komponentin (sovelluksen tai palvelun) olisi kommunikoitava toisen komponentin kanssa tietomuodossa, joka olisi riippumaton molemmista komponenttitietomuodoista.
kaksi asiaa, joita tässä kannattaa korostaa. Ensin määrittelin komponentin joko sovellukseksi tai palveluksi, koska tällaisia malleja käytetään/käytettiin sovellusten integroinnin ja palvelulähtöisyyden yhteydessä. Toiseksi kyse on käsitteestä, jota olisi käytettävä yksinomaan kuljetustietojen muodossa. Sinun ei pitäisi käyttää canonicalista tietomuotoa tietovarastosi sisäisenä rakenteena.
teoriassa edut ovat melko ilmeiset. Kanoninen tietomuoto vähentää sovellusten välistä kytkentää, vähentää käännösten määrää, jotka on kehitettävä komponenttijoukon integroimiseksi jne. Aika mielenkiintoista, eikö? Yksi ainoa tietomalli on ymmärrettävä koko IT-maiseman ja joukko ihmisiä (Kehittäjät, järjestelmäanalyytikot, liiketoiminnan sidosryhmät, jne.), jotka voivat jakaa saman näkemyksen tietystä käsitteestä.
käytännön tarkoituksiin tällaisten mallien toteuttaminen on kuitenkin harvoin tehokasta.
henkilö ei ole sama käsite vakuutusyhtiön markkinointi-ja tukiosastolle. Ilmaliikenteen hallintajärjestelmän lennolla on eri merkitys riippuen siitä, täyttikö sen lentäjä vai onko kyseessä jatkuva lento ilmatilasi päällä. PLM-osalla on täysin erilainen edustus riippuen siitä, onko se juuri suunniteltu vai onko sitä ylläpidettävä tukitiimillä.
useimmissa yhteyksissä kanonisen tietomallin suunnittelu johtaa suureen tietomalliin, jossa on täysi joukko valinnaisia attribuutteja ja hyvin vähän pakollisia (kuten tunnisteet). Vaikka se oli ensisijaisesti suunniteltu helpottamaan komponenttien integrointia, voit vain vaikeuttaa sitä. Sillä välin, malli luo paljon turhautumista käyttäjien keskuudessa, koska sen luontainen monimutkaisuus (kannalta hyödyntäminen ja hallinta). Lisäksi, mitä tulee kytkentäongelmaan, olet vain siirtämässä sitä jonnekin muualle. Sen sijaan, että ne olisi kytketty yhteen komponenttitietomuotoon, niistä tulee tiukasti kytkettyjä yhteen yhteiseen tietomuotoon, jota koko IT-maisema käyttää ja johon kohdistuu hyvin toistuvia muutoksia.
pähkinänkuoressa kanoninen tietomalli tulisi useimmissa yhteyksissä pitää antikuviona. Mikä on toinen vaihtoehto kuin harkitsee sinun pitäisi silti haluta minimoida riippuvuudet kahden komponentin vaihtaa tietoja?
Domain Driven Design (DDD) suosittelee rajatun kontekstin käsitteen käyttöönottoa. Rajattu asiayhteys on yksinkertaisesti eksplisiittinen asiayhteys, jossa malli pätee selvin rajauksin muiden rajattujen asiayhteyksien kanssa. Organisaatiosta riippuen rajattu asiayhteys voi viitata funktionaaliseen toimialueeseen, jossa objektia käytetään, se voi viitata itse objektitilaan jne.
tällöin kanoninen tietomalli sellaisenaan olisi yksinkertaisesti seuraavan kaavion keltainen osa:
A: n, B: n ja C: n leikkauspiste edustaa niiden ominaisuuksien joukkoa, joiden on oltava olemassa asiayhteydestä riippumatta (periaatteessa edellisen suuren CDM: n pakolliset ominaisuudet). Tämä osa on edelleen huolellisesti suunniteltu, koska sen keskeinen rooli. On kuitenkin tärkeää pysyä pragmaattisena. Jos omassa kontekstissa ei ole järkevää, että on tällainen yhteinen malli, kannattaa se vain hylätä.
tärkeää on myös kahden asiayhteyden (A ja B, B ja C, C ja A) välinen leikkauspiste. Miten kartoittaa yhden objektin esitys asiayhteydestä toiseen? Mitkä ovat ne eksplisiittiset ominaisuudet, jotka pitäisi jakaa kahdessa yhteydessä? Mitkä ovat yhteiset liiketoimintarajoitteet kahden asiayhteyden välillä? Näihin kysymyksiin pitäisi vielä poikittaisella joukkueella vastata, mutta bisneksen näkökulmasta on järkevää ottaa ne esille. Näin ei ole aina ollut, jos CDM on jaettu mahdollisesti vastakkaisissa yhteyksissä.
kuitenkin niiden osien osalta, joita ei jaeta muihin yhteyksiin (valkoisella), sen ei pitäisi olla osa yritystietomallia. Sinun pitäisi olla pragmaattinen. Esimerkiksi, jos osajoukko on tietyn verkkotunnuksen erityinen, sen pitäisi olla jopa verkkotunnuksen asiantuntijoiden mallintaa se itse.
yksi keskeinen haaste on kuitenkin tunnistaa nämä rajatut asiayhteydet ja tässä voisi olla syytä muistuttaa Conwayn laista:
mikä tahansa organisaatio, joka suunnittelee järjestelmän, tuottaa väistämättä mallin, jonka rakenne on kopio organisaation viestintärakenteesta.
rajattuja asiayhteyksiä ei välttämättä kartoiteta nykyiseen organisaatioon. Esimerkiksi rajattu asiayhteys voi käsittää useita osastoja. Organisaatiosiilojen murtamisen pitäisi edelleen olla useimpien yritysten tavoite.
lisäksi DDD ottaa käyttöön korruption vastaisen kerroksen (ACL) käsitteen. Tämä malli voi viitata ratkaisuun, joka koskee perinteistä siirtymistä (ottamalla käyttöön välityskerros vanhan ja uuden järjestelmän välille tietojen laatuongelmien estämiseksi jne.). Mutta meidän yhteydessä, kun puhumme korruptiosta, se liittyy tietomallinnusvelkaan, jonka voit ottaa käyttöön lyhyen aikavälin ongelmien ratkaisemiseksi.
Otetaanpa esimerkki kahdesta järjestelmästä, jotka vastaavat tietyn PLM-osan tilan hallinnasta (osa on fyysinen esine, joka on valmistettu tai ostettu ja sitten koottu, kuten esimerkiksi helikopterin roottori). Yksi vanha järjestelmä (kutsutaan sitä SystemA) on vastuussa hallita suunnitteluvaiheen ja sinun täytyy toteuttaa uusi järjestelmä (kutsutaan sitä SystemZ) vastuussa hallita ylläpitovaihe. Koko IT – sovellusmaisema jakaa saman yhteisen osatunnuksen (partId) lukuun ottamatta Systemaa, joka ei ole tietoinen siitä. Partidin sijaan SystemA hallinnoi omaa tunnistettaan, systemaidia. Koska SystemZ on kutsuttava Systememaksi systememaidin avulla, heuristinen voisi olla systememaidin integroiminen osaksi SystemZ-tietomallia.
tätä yleistä virhettä kannattaa välttää. Olet yksinkertaisesti vioittanut tietomallisi lyhyen aikavälin tilanteen vuoksi.
eturistiside on voinut olla ratkaisu tähän. SystemZ olisi voinut toteuttaa oman tietomuotonsa (ilman systemaidin kaltaista ulkoista korruptiota). Tällöin olisi ollut jopa välitason hallita käännös välillä partId ja systemAId.
sovellettuna aiheeseemme, ACL-kuvio pakottaa toteuttamaan kerroksen kahden eri rajatun kontekstin välillä. Komponentti ei ole tietoinen siitä, miten kutsua toista komponenttia, joka ei kuulu sen omaan rajattuun kontekstiin. Sen sijaan komponentti on tietoinen vain siitä, miten se kartoittaa oman tietorakenteensa sen rajatun kontekstin tietomuodosta, johon se kuuluu.
muuten tämä on nyrkkisääntö. Osa saa kuulua vain yhteen rajoitettuun yhteyteen. Tämän vuoksi DDD sopii erinomaisesti mikropalveluiden arkkitehtuuriin. Hienorakeisuuden vuoksi tätä sääntöä on helpompi noudattaa.
yhteenvetona voidaan todeta, että kanoninen malli sellaisenaan on useimmissa tapauksissa katsottava antikuvioksi. Sinun pitäisi yrittää toteuttaa rajattu kontekstikäsite, joka tarkoittaa yhtä mallia kontekstia kohti, jossa on selkeät rajat kontekstien välillä. Kahden eri rajatuissa yhteyksissä olevan komponentin olisi kommunikoitava korruption vastaisen kerroksen kautta, jotta estetään tietojen mallinnus korruptiosta.