a kanonikus adatmodellt a vállalati integrációs minták definiálják, mint megoldást a függőségek minimalizálására a különböző adatformátumokat használó alkalmazások integrálásakor. Más szavakkal, egy összetevőnek (alkalmazásnak vagy szolgáltatásnak) kommunikálnia kell egy másik összetevővel olyan adatformátumon keresztül, amely független lenne mindkét összetevő adatformátumától.
két dolgot kell kiemelni itt. Először definiáltam egy komponenst alkalmazásként vagy szolgáltatásként, mert az ilyen modelleket az alkalmazásintegráció és a szolgáltatásorientáció összefüggésében használták/használták. Másodszor, itt egy olyan koncepcióról beszélünk, amelyet kizárólag közlekedési adatformátumként kell használni. Nem szabad kanonikus adatformátumot használni az adattár belső struktúrájaként.
elméletileg az előnyök elég nyilvánvalóak. A kanonikus adatformátum csökkenti az alkalmazások közötti összekapcsolást, csökkenti az összetevők integrálásához fejlesztendő fordítások számát stb. Elég érdekes, igaz? Egyetlen adatmodell érthető az egész informatikai környezet és az emberek (Fejlesztők, rendszerelemzők, üzleti érdekeltek stb.), akik ugyanazt a jövőképet oszthatják meg egy adott koncepcióval.
gyakorlati célokra az ilyen modellek megvalósítása azonban ritkán hatékony.
egy személy nem ugyanaz a koncepció a biztosítótársaság marketing és támogatási osztályán. A légiforgalmi irányítási rendszer repülésének más jelentése van attól függően, hogy pilóta töltötte-e be, vagy folyamatban lévő repülésről van szó a légtér tetején. A PLM rész teljesen más ábrázolással rendelkezik, attól függően, hogy éppen tervezték-e, vagy egy támogató csapatnak kell-e fenntartania.
a legtöbb kontextusban a kanonikus adatmodell megtervezése nagy adatmodellt eredményez, amely opcionális attribútumok teljes készletét és nagyon kevés kötelező attribútumot tartalmaz (például az azonosítókat). Annak ellenére, hogy elsősorban az összetevők integrációjának megkönnyítésére tervezték, csak bonyolítja. Időközben a modell sok frusztrációt okoz a felhasználók körében a benne rejlő összetettség miatt (a felhasználás és a menedzsment szempontjából). Továbbá, ami a kapcsolási kérdést illeti, csak áthelyezi valahol máshol. Ahelyett, hogy egy komponens adatformátumhoz kapcsolódna, szorosan összekapcsolódik egy közös adatformátummal, amelyet az egész informatikai környezet használ, és nagyon gyakori változásoknak van kitéve.
dióhéjban a legtöbb kontextusban a kanonikus adatmodellt anti-mintának kell tekinteni. Mi a másik lehetőség, mint annak megfontolása, hogy továbbra is minimalizálni kell az adatcsere két összetevője közötti függőségeket?
a Domain Driven Design (DDD) a korlátozott kontextus fogalmának bevezetését javasolja. A korlátozott kontextus egyszerűen egy explicit kontextus, amelyben egy modell egyértelmű határokkal érvényes más korlátozott kontextusokkal. A szervezetétől függően a korlátozott kontextus hivatkozhat egy funkcionális tartományra, amelyben egy objektumot használnak, hivatkozhat magára az objektumállapotra stb.
ebben az esetben a kanonikus adatmodell önmagában egyszerűen a következő ábra sárga része lenne:
az A, B és C metszéspontja azokat az attribútumokat jelöli, amelyeknek a kontextustól függetlenül ott kell lenniük (alapvetően az előző nagy CDM kötelező attribútumai). Ezt a részt központi szerepe miatt továbbra is gondosan meg kell tervezni. Fontos azonban, hogy pragmatikusak maradjunk. Ha az Ön kontextusában nincs értelme egy ilyen közös modellnek, akkor egyszerűen el kell dobnia.
ami szintén fontos, az két összefüggés metszete (A és B, B és C, C és A). Hogyan lehet leképezni egy objektum ábrázolását egyik kontextusból a másikba? Melyek azok az explicit attribútumok, amelyeket meg kell osztani két kontextusban? Mik a közös üzleti korlátok két kontextus között? Ezekre a kérdésekre továbbra is keresztirányú csapatnak kell válaszolnia, de üzleti szempontból érdemes felvetni őket. Nem mindig volt ez a helyzet egyetlen, potenciálisan ellentétes összefüggésekben megosztott CDM esetében.
Mindazonáltal, ami azokat a részeket illeti, amelyeket nem osztanak meg más kontextusokkal (fehéren), nem lehet része egy vállalati adatmodellnek. Pragmatikusnak kell lenned. Például, ha egy részhalmaz egy adott domainre jellemző,akkor a domain szakértőinek kell azt modellezniük.
az egyik legfontosabb kihívás azonban az, hogy azonosítsuk ezeket a határolt összefüggéseket, és érdemes lehet itt emlékeztetni a Conway-törvényre:
bármely szervezet, amely rendszert tervez, elkerülhetetlenül olyan tervet készít, amelynek szerkezete a szervezet kommunikációs struktúrájának másolata.
a határolt összefüggéseket nem feltétlenül kell leképezni az aktuális szervezetre. Például egy korlátozott kontextus több osztályt is magában foglalhat. A szervezeti silók megtörésének továbbra is célnak kell lennie a legtöbb vállalat számára.
ezenkívül a DDD bevezeti a korrupcióellenes réteg (ACL) fogalmát. Ez a minta egy régi áttelepítés megoldására utalhat (egy közvetítő réteg bevezetésével a régi és az új rendszer között az adatminőségi problémák megelőzése érdekében stb.). De a mi kontextusunkban, amikor korrupcióról beszélünk, az adatmodellezéshez kapcsolódik adósság bevezetheti a rövid távú problémák megoldására.
vegyük a PLM alkatrész adott állapotának kezelésére szolgáló két rendszer példáját (az alkatrész egy fizikai elem, amelyet előállítottak vagy megvásároltak, majd összeszereltek, mint például egy helikopter rotor). Egy régi rendszer (nevezzük SystemA-nak) felel a tervezési szakasz kezeléséért, a karbantartási szakasz kezeléséért pedig egy új rendszert (nevezzük SystemZ-nek) kell végrehajtania. A teljes informatikai alkalmazáskörnyezet ugyanazt a közös részazonosítót (partId) használja, kivéve a SystemA-t, amely nem ismeri azt. A partId helyett a SystemA kezeli a saját azonosítóját, a systemAId-t. Mivel SystemZ kell hívni SystemA segítségével systemAId, egy heurisztikus lehet integrálni systemAId részeként SystemZ adatmodell.
ez egy gyakori hiba, amelyet el kell kerülni. Egyszerűen megrontotta az adatmodellt egy rövid távú helyzet miatt.
az ACL minta megoldás lehetett volna itt. A SystemZ megvalósíthatta volna saját adatformátumát (bármilyen külső korrupció nélkül, mint például a systemAId). Akkor egy közvetítő réteg feladata lett volna a partId és a systemAId közötti fordítás kezelése.
a témánkra alkalmazva az ACL minta kikényszeríti egy réteg megvalósítását két különböző határolt kontextus között. Egy komponens nem tudja, hogyan hívhat meg egy másik komponenst, amely nem része a saját korlátozott kontextusának. Ehelyett egy összetevő csak azzal van tisztában, hogyan lehet saját adatszerkezetét leképezni annak a korlátozott kontextusnak az adatformátumán, amelyhez tartozik.
egyébként ez egy ökölszabály. Egy összetevő csak egy korlátozott kontextushoz tartozhat. Ez az oka annak is, hogy a DDD kiválóan alkalmas a mikroszolgáltatások architektúrájára. A finomszemcsés szemcsézettség miatt könnyebb betartani ezt a szabályt.
összefoglalva, a kanonikus modellt mint olyat a legtöbb esetben anti-mintának kell tekinteni. Meg kell próbálnia megvalósítani a korlátozott kontextus fogalmát, amely kontextusonként egy modellt jelent, kifejezett határokkal a kontextusok között. Két összetevőnek, amelyek különböző korlátozott kontextusok részét képezik, korrupcióellenes rétegen keresztül kell kommunikálnia az adatmodellezés korrupciójának megelőzése érdekében.