Az egyes mikroszolgáltatások tartománymodell-határainak azonosítása

Jótanács

Ez a tartalom egy részlet a '.NET Microservices Architecture for Containerized .NET Applications' című eBook-ból, amely elérhető a .NET Docs oldalon, vagy ingyenesen letölthető PDF formátumban, amely offline módban is olvasható.

PDF letöltése

Az egyes mikroszolgáltatások modellhatárainak és méretének meghatározásánál nem az a cél, hogy a lehető legrészletesebb elkülönítést érje el, bár ha lehetséges, a kis mikroszolgáltatások felé kell irányulnia. Ehelyett a cél az, hogy a tartományismeretek által irányított legérthetőbb elkülönítést érje el. A hangsúly nem a méreten, hanem az üzleti képességeken van. Emellett, ha az alkalmazás egy bizonyos területén egyértelmű kohézióra van szükség nagy számú függőség alapján, az azt jelzi, hogy egyetlen mikroszolgáltatásra is szükség van. A kohézió a mikroszolgáltatások szétválasztásának vagy csoportosításának egyik módja. Végső soron, miközben további ismereteket szerez a tartományról, iteratív módon kell módosítania a mikroszolgáltatás méretét. A megfelelő méret megtalálása nem egyszeri próbálkozás.

Sam Newman, a mikroszolgáltatások elismert támogatója és a Mikroszolgáltatások létrehozása című könyv szerzője kiemeli, hogy a mikroszolgáltatásokat a korábban bemutatott Kötött környezet (BC) minta (a tartományalapú tervezés része) alapján kell megterveznie. Néha a BC több fizikai szolgáltatásból állhat, de nem fordítva.

Egy konkrét tartományentitással rendelkező tartománymodell egy konkrét BC-n vagy mikroszolgáltatáson belül alkalmazható. A BC elválasztja egy tartománymodell alkalmazhatóságát, és egyértelmű és közös képet ad a fejlesztői csapat tagjainak arról, hogy mi kell összetartónak, és mi fejleszthető egymástól függetlenül. Ezek ugyanazok a mikroszolgáltatásokra vonatkozó célok.

Egy másik eszköz, amely tájékoztatja a tervezési választást, a Conway törvénye, amely kimondja, hogy az alkalmazás tükrözi annak a szervezetnek a társadalmi határait, amely azt létrehozta. De néha az ellenkezője igaz, -the vállalat szervezetét a szoftver hozza létre. Előfordulhat, hogy módosítania kell a Conway törvényét a vállalat szervezetére vonatkozóan, és úgy építenie fel a határokat, ahogyan annak szervezését kívánja, az üzleti folyamatokkal kapcsolatos tanácsadást előtérbe helyezve.

A határos környezetek azonosításához használhatja a környezetleképezési minta nevű DDD-mintát. A környezetleképezéssel azonosíthatja az alkalmazás különböző környezeteit és azok határait. Gyakran előfordul például, hogy minden kis alrendszerhez eltérő környezet és határ tartozik. A környezeti térkép lehetővé teszi a tartományok közötti határok definiálásának és explicit kialakításának módját. A BC önálló, és magában foglalja egyetlen tartomány -details részleteit - például a domain entitásokat -, és meghatározza az integrációs szerződéseket más BC-kkel. Ez hasonló a mikroszolgáltatások definícióihoz: autonóm, implementál bizonyos tartományi képességeket, és interfészeket kell biztosítania. Ezért a környezetleképezés és a kötött környezet minta jó módszer a mikroszolgáltatások tartománymodell-határainak azonosítására.

Egy nagy alkalmazás tervezésekor látni fogja, hogyan töredezett a tartománymodellje – a katalógustartomány tartományszakértője például a katalógusban és a készlettartományokban eltérően nevez el entitásokat, mint például a szállítási tartomány szakértője. Vagy a felhasználói tartományi entitás mérete és száma eltérő lehet, amikor egy CRM-szakértővel foglalkozik, aki minden részletet el szeretne tárolni az ügyfélről, mint egy rendelési tartományszakértő, akinek csak részleges adatokra van szüksége az ügyfélről. Nagyon nehéz egyértelműsíteni az összes tartománykifejezést a nagy alkalmazáshoz kapcsolódó összes tartományban. De a legfontosabb az, hogy ne próbálja meg egyesíteni a feltételeket. Ehelyett fogadja el az egyes tartományok által biztosított különbségeket és gazdagságot. Ha a teljes alkalmazáshoz egységes adatbázist próbál létrehozni, az egyesített szókincsre tett kísérletek kényelmetlenek lesznek, és nem fognak helyesen hangzani a több tartomány szakértőinek. Ezért a (mikroszolgáltatásként implementált) BCS-k segítségével egyértelművé teheti, hogy hol használhat bizonyos tartományi feltételeket, és hol kell felosztania a rendszert, és további, különböző tartományokkal rendelkező BCs-ket kell létrehoznia.

Tudni fogja, hogy az egyes BC- és tartománymodellek megfelelő határaival és méreteivel rendelkezik, ha kevés erős kapcsolat van a tartománymodellek között, és általában nem kell több tartománymodell adatait egyesítenie a tipikus alkalmazásműveletek végrehajtásakor.

Talán a legjobb válasz arra a kérdésre, hogy az egyes mikroszolgáltatások tartománymodelljeinek mekkoranak kell lenniük, az a következő: egy autonóm BC-vel kell rendelkeznie, amennyire csak lehetséges, amely lehetővé teszi a munkavégzést anélkül, hogy folyamatosan más környezetekre (más mikroszolgáltatások modelljeire) kellene váltania. A 4–10. ábrán láthatja, hogy több mikroszolgáltatás (több BCs) hogyan rendelkezik saját modellel, és hogyan határozhatók meg az entitások az alkalmazás egyes azonosított tartományainak konkrét követelményeitől függően.

Ábra 4–10. Entitások és mikroszolgáltatási modellek határainak azonosítása

A 4–10. ábra egy online konferenciafelügyeleti rendszerhez kapcsolódó mintaforgatókönyvet szemléltet. Ugyanaz az entitás jelenik meg a "Felhasználók", a "Vevők", a "Kifizetők" és a "Vevők" kifejezéssel a kötött környezettől függően. Azokat a BC-ket azonosította, amelyek mikroszolgáltatásként implementálhatók, a domain szakértők által meghatározott tartományok alapján. Mint látható, vannak olyan entitások, amelyek csak egyetlen mikroszolgáltatási modellben vannak jelen, például a Fizetési mikroszolgáltatásban lévő Kifizetések. Ezek könnyen implementálhatók lesznek.

Lehetnek azonban olyan entitások is, amelyek eltérő alakúak, de azonos identitással rendelkeznek a több mikroszolgáltatás több tartománymodellje között. A Felhasználó entitás például a Conferences Management mikroszolgáltatásban van azonosítva. Ugyanaz a felhasználó, ugyanazzal az identitással, a Rendelési mikroszolgáltatásban a Vevő néven szerepel, a Fizetési mikroszolgáltatásban a Fizető néven, és az Ügyfélszolgálat mikroszolgáltatásban az Ügyfél néven is szerepel. Ennek az az oka, hogy az egyes tartományi szakértők által használt mindenütt használt nyelvtől függően a felhasználónak más perspektívája lehet még különböző attribútumokkal is. Előfordulhat, hogy a Mikroszolgáltatás-modellBen a Conferences Management nevű felhasználói entitás rendelkezik a legtöbb személyes adatattribútummal. Azonban ugyanarra a felhasználóra, aki a Payer szerepében van a Fizetési mikroszolgáltatásban, vagy Ügyfél szerepében az Ügyfélszolgálati mikroszolgáltatásban, lehet, hogy nincs szükség ugyanarra az attribútumlistára.

Hasonló megközelítést a 4–11. ábra szemléltet.

4–11. ábra. Hagyományos adatmodellek felbontása több tartománymodellbe

Ha egy hagyományos adatmodellt határolókeretes környezetek között bont fel, különböző entitásokkal rendelkezhet, amelyek azonos identitással rendelkeznek (a vevő szintén felhasználó), és mindegyik kötött környezetben különböző attribútumokkal rendelkeznek. Láthatja, hogy a felhasználó hogyan jelen van a Conferences Management mikroszolgáltatás-modellben felhasználói entitásként, és a Vevő entitás formájában is jelen van a Díjszabás mikroszolgáltatásban, alternatív attribútumokkal vagy részletekkel a felhasználóról, amikor valójában vevő. Előfordulhat, hogy minden mikroszolgáltatásnak vagy BC-nek nincs szüksége egy felhasználói entitáshoz kapcsolódó összes adatra, csak annak egy részére, a megoldandó probléma vagy a környezet függvényében. A díjszabási mikroszolgáltatás-modellben például nincs szükség a felhasználó címére vagy nevére, csak az azonosítóra (identitásként) és az állapotra, ami hatással lesz a kedvezményekre, amikor a helyek vevőnkénti díjszabását meg kell adni.

A Seat entitás neve azonos, de mindegyik tartománymodellben eltérő attribútumokkal rendelkezik. A Seat ugyanazon azonosító alapján osztja meg az identitást, mint a Felhasználó és Vevő.

Alapvetően létezik egy olyan felhasználó közös fogalma, amely több szolgáltatásban (tartományban) létezik, és amelyek mindegyike az adott felhasználó identitását osztja meg. Az egyes tartományi modellekben azonban további vagy eltérő részletek is lehetnek a felhasználói entitásról. Szükséges tehát, hogy egy felhasználói entitást áthelyezzenek az egyik tartományból (mikroszolgáltatásból) a másikba.

Számos előnnyel jár, ha ugyanazt a felhasználói entitást nem osztják meg azonos számú attribútummal a tartományok között. Az egyik előnye a duplikáció csökkentése, hogy a mikroszolgáltatási modellek ne rendelkezzenek olyan adatokkal, amelyekre nincs szükségük. Egy másik előny egy elsődleges mikroszolgáltatás, amely entitásonként egy bizonyos adattípust birtokol, így az adott adattípus frissítéseit és lekérdezéseit csak az adott mikroszolgáltatás vezérli.

ElőzőKövetkező