Olyan homlokzati vagy adapterréteg implementálása különböző alrendszerek között, amelyek nem azonos szemantikával rendelkeznek. Ez a réteg lefordítja az egyik alrendszer által a másik alrendszerre irányuló kéréseket. Ezzel a mintával biztosíthatja, hogy az alkalmazás kialakítását ne korlátozzák a külső alrendszerek függőségei. A mintáról először Eric Evans írt Domain-Driven Design című könyvében.
Kontextus és probléma
A legtöbb alkalmazás más rendszerekre támaszkodik bizonyos adatokért vagy funkciókért. Ha például egy örökölt alkalmazást egy modern rendszerbe migrálnak, annak továbbra is szüksége lehet a meglévő régebbi erőforrásokra. Az új funkcióknak képesnek kell lenniük meghívni a régi rendszert. Ez különösen igaz fokozatos migrálás esetén, ahol az idő előrehaladtával egy nagyobb alkalmazás különböző funkcióit helyezik át egy modern rendszerbe.
A régebbi rendszerekben gyakoriak a minőségbeli hibák (pl. szövevényes adatsémák, elavult API-k). A korábbi rendszerek funkciói és technológiái nagyban eltérhetnek a modern rendszerekétől. Ahhoz, hogy az új alkalmazás együttműködhessen a régebbi alkalmazással, nagy eséllyel támogatnia kell elavult infrastruktúrákat, protokollokat, adatmodelleket, API-kat vagy más olyan funkciókat, amelyeket máskülönben nem tennénk egy korszerű alkalmazás részévé.
Az új és a régebbi rendszer közötti hozzáférés fenntartása érdekében előfordulhat, hogy az új rendszernek alkalmazkodnia kell néhányhoz a korábbi rendszer API-jai vagy más szemantikái közül. Ha ezek a régebbi funkciók hibásak, támogatásukkal „megsérül” a máskülönben letisztult tervezésű korszerű alkalmazás.
Hasonló problémák merülhetnek fel minden olyan külső rendszerrel kapcsolatban, amelyet a fejlesztői csapat nem irányít, nem csak az örökölt rendszerekkel.
Megoldás
A különböző alrendszerek elkülönítéséhez helyezzen el közöttük egy korrupciógátló réteget. Ez a réteg lefordítja a két rendszer közötti kommunikációt, így az egyik rendszer változatlan marad, míg a másik elkerülheti annak kialakítását és technológiai megközelítését.
A fenti ábrán egy két alrendszerrel rendelkező alkalmazás látható. Az A alrendszer egy sérülésgátló rétegen keresztül hívja meg a B alrendszert. Az A alrendszer és a sérülésgátló réteg közötti kommunikáció mindig az A alrendszer adatmodelljét és architektúráját használja. A sérülésgátló rétegből a B alrendszerbe irányuló hívások megfelelnek az alrendszer adatmodelljének vagy metódusainak. A sérülésgátló réteg tartalmazza az összes logikát, amely a két rendszer közötti fordításhoz szükséges. A réteget implementálhatja egy alkalmazáson belüli összetevőként, de akár független szolgáltatásként is.
Problémák és megfontolandó szempontok
- A sérülésgátló réteg késéseket okozhat a két rendszer közötti hívásoknál.
- A sérülésgátló réteg egy további szolgáltatást képez, amely kezelést és karbantartást igényel.
- Gondolja át, hogyan lesz skálázva a sérülésgátló réteg.
- Fontolja meg, hogy egynél több sérülésgátló rétegre lenne-e szüksége. Érdemes lehet funkció szerint felbontani több, különböző technológiákat és nyelveket használó szolgáltatásra, de más okokból is particionálhatja a sérülésgátló réteget.
- Gondolja át, hogy egyéb alkalmazásaihoz vagy szolgáltatásaihoz képest hogyan fogja kezelni a sérülésgátló réteget. Hogyan fogja integrálni a monitorozási, kiadási és konfigurációs folyamataiba?
- Győződjön meg arról, hogy a tranzakciós és adatkonzisztencia fenntartható és monitorozható.
- Fontolja meg, hogy a sérülésgátló rétegnek kezelnie kell-e a különböző alrendszerek közötti összes kommunikációt, vagy csak a funkciók egy részhalmazát.
- Ha a sérülésgátló réteg egy alkalmazásmigrálási stratégia része, fontolja meg, hogy végleges lesz-e, vagy az összes régi funkció áttelepítése után megszűnik.
- Ezt a mintát a fenti különböző alrendszerek szemléltetik, de más szolgáltatásarchitektúrákra is alkalmazhatók, például az örökölt kód monolitikus architektúrákba való integrálására.
Mikor érdemes ezt a mintát használni?
Használja ezt a mintát, ha:
- Több lépésben tervez migrációt végrehajtani, de szükség van a régi és az új rendszer közötti integráció fenntartására.
- Két vagy több alrendszer eltérő szemantikával rendelkezik, de továbbra is kommunikálnia kell.
Nem érdemes ezt a mintát használni, ha nincsenek jelentős szemantikai különbségek az új és a régebbi rendszer között.
Számítási feladatok tervezése
Az építészeknek értékelniük kell, hogyan használható a korrupció elleni réteg minta a számítási feladat kialakításában az Azure Well-Architected Framework pilléreiben foglalt célok és alapelvek kezelésére. Példa:
| Pillér | Hogyan támogatja ez a minta a pillércélokat? |
|---|---|
| Az operatív kiválóság szabványosított folyamatok és a csapat kohéziója révén segít a számítási feladatok minőségének biztosításában. | Ez a minta segít annak biztosításában, hogy az új összetevők tervezése ne változhasson az örökölt implementációktól, amelyek eltérő adatmodellekkel vagy üzleti szabályokkal rendelkezhetnek az örökölt rendszerekkel való integráláskor, és csökkenthetik az új összetevők műszaki adósságát, miközben továbbra is támogatják a meglévő összetevőket. - OE:04 Eszközök és folyamatok |
Mint minden tervezési döntésnél, fontolja meg az ezzel a mintával bevezethető többi pillér céljaival szembeni kompromisszumokat.