Az egyes mikroszolgáltatások tartománymodell-határainak azonosítása
Tipp.
Ez a tartalom egy részlet a .NET-alkalmazásokhoz készült .NET-alkalmazásokhoz készült eBook, .NET Microservices Architecture című eBookból, amely elérhető a .NET Docs-on vagy egy ingyenesen letölthető PDF-fájlként, amely offline módban is olvasható.
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 megkeresése nem egy lövéses folyamat.
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ás a Conway törvénye, amely kimondja, hogy az alkalmazás tükrözi a társadalmi határait a szervezet, hogy az azt. De néha az ellenkezője igaz - a vállalat szervezetét a szoftver alkotja. Előfordulhat, hogy vissza kell fordítania a Conway törvényét, és úgy kell felépítenie a határokat, ahogyan a vállalatot rendszerezni szeretné, és az üzleti folyamatokkal kapcsolatos tanácsadás felé hajl.
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 részleteit (például a tartományi 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.
4–10. ábra. 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. Számos olyan BCS-t azonosított, amelyek mikroszolgáltatásként implementálhatók az Ön számára 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 Kifizetések a Fizetési mikroszolgáltatásban. 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ők, vagy a Fizetési mikroszolgáltatásban a Payer nevű felhasználó, és még az Ügyfélszolgálat mikroszolgáltatásban szereplő Ügyfél nevű felhasználó is. 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. Előfordulhat azonban, hogy ugyanaz a felhasználó, aki a mikroszolgáltatás fizetésében vagy a mikroszolgáltatás-ügyfélszolgálat ügyfélalakzatában a Payer alakjában van, előfordulhat, hogy nincs szüksége ugyanazzal az attribútumlistával.
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 azonban ugyanaz alapján osztja meg az identitást, mint a Felhasználó és a 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. Ezért egy felhasználói entitást le kell képezni az egyik tartományból (mikroszolgáltatásból) egy 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.
