Logický centralizační vzor - Logic centralization pattern

Logická centralizace je návrhový vzor, aplikované v rámci orientace na služby paradigma designu, jehož aplikace si klade za cíl zvýšit potenciál agnostické logiky pro opětovné použití [1] zajištěním těchto služeb[2] neobsahují redundantní agnostickou logiku a že každá opakovaně použitelná logika by měla být reprezentována pouze službou, která má nejvhodnější funkční kontext.[3][4]

Odůvodnění

Jak se vyvíjí stále více služeb, existuje neustálé riziko, že mohou být vytvářeny služby s redundantní funkcí. Ačkoli použití Normalizace služby designový vzor pomáhá eliminovat tuto nadbytečnost, ale právě tím, že má sadu normalizovaných služeb sama o sobě, nezaručuje, že by byly znovu použity, jak se původně předpokládalo. V případě agnostických služeb[5] tento problém může vážně omezit skutečné opětovné použití těchto služeb, protože projektový tým (tým A) se může rozhodnout znovu nepoužívat existující službu, např. vyžaduje data, která odpovídají složitému schématu, a místo toho vyvine odlehčenou službu, která tuto práci pouze provede. Výsledkem je, že stejná opakovaně použitelná logika nyní existuje se dvěma různými službami, zatímco stávající služba měla být vyvinuta, i když neobsahovala nejvhodnější chuť této funkce. Tento efekt se znásobí, když jiný tým (tým B), který doufá, že najde funkčnost v rámci existující služby, protože hranice služby pokrývá požadovanou funkčnost, nenajde ji a místo toho začne používat nově vytvořenou službu od týmu A. skutečná opětovná použitelnost původní agnostické služby klesá a současně se vytváří řízení problém, pokud jde o údržbu původní a nové služby, protože nyní existuje opakovaně použitelná logika decentralizovaným způsobem.

Aby bylo zajištěno, že určitý typ logiky opakovaně použitelného řešení je uzavřen pouze jednou konkrétní agnostickou službou, návrhový vzor Logická centralizace vyžaduje, aby bylo nutné zavést designové standardy, které vynutí správné používání agnostických služeb. To dává spotřebitelům služeb jistotu, že k funkcím přistupují prostřednictvím správné služby.[6]

Používání

Diagram A
Diagram A
Místo použití existující červené služby se Project Team 1 uchýlí k vytvoření nové redundantní červené služby, protože bylo snadné vyvinout novou službu, která bude efektivnější vzhledem k jejich krátkodobým požadavkům.
Diagram A
Diagram A
Za přítomnosti celopodnikového designového standardu je zakázán přístup spotřebitelů služeb k redundantní červené službě vytvořené Project Team 2 a místo toho jsou nuceni používat stávající červenou službu vytvořenou Project Team 1. Podobně je Project Team 3 zakázáno vytvářet jakoukoli novou službu, jejíž funkčnost spadá do existující červené služby, v důsledku toho Project Team 3 používá / vyvíjí stávající červenou službu vytvořenou Project Team 1.

Aplikace tohoto návrhového vzoru vyžaduje nastavení „oficiálních koncových bodů“ (služeb), které představují určitý typ funkčnosti, tj. Funkčnost, která spadá pod určitý typ funkční domény. Přístup k jakýmkoli dalším službám, které mohou nabízet stejnou funkcionalitu, je zakázán a pro určitý typ funkčnosti je zpřístupněna pouze jedna služba.[7] Omezením přístupu k dalším službám se snižuje zátěž správy, protože logika je nyní omezena v rámci jedné služby. Kdykoli je požadována nová funkce, kterou aktuálně nenabízí žádná ze stávajících služeb, je třeba nejprve zkontrolovat funkční kontexty stávajících služeb a pokud nová funkce spadá pod hranici již existující služby, měla by být přidán do této služby. To vyžaduje celopodnikový standard, který vynucuje centralizaci logiky. Aby bylo zajištěno, že vývojáři služeb budou znát hranice služby, Metadata Centralization[8] lze použít návrhový vzor. To pomáhá při vytváření centralizovaného úložiště informací o funkčních kontextech a funkcích poskytovaných službami. Návrhový vzor centralizace logiky při použití společně s centralizací smlouvy[9] designový vzor, ​​tvoří oficiální koncový bod[10] návrhový vzor. Aplikace návrhového vzoru Logic Centralization dále pomáhá při aplikaci Opakovaná použitelnost služby a Skladatelnost služeb principy návrhu zajištěním toho, že každá služba obsahuje správný typ opakovaně použitelných funkcí, aby ji bylo možné skládat opakovaně.

Úvahy

Aby bylo možné použít tento návrhový vzor, ​​je třeba zajistit, aby všechny projektové týmy v celém podniku rozuměly a souhlasily se správným používáním agnostických služeb a nevytvářely žádné nové služby, které by sloužily pouze krátkodobým požadavkům projektu. To může také ovlivnit dodací lhůty projektu, protože využití stávajících agnostických služeb (a jejich vývoj podle pokynů tohoto vzoru) by vyžadovalo více času a úsilí. Důvodem je, že služby v aktuálním projektu nemusí být schopny využívat agnostické služby, dokud se nezmění jejich vlastní design.

Reference

  1. ^ Logika, která nepatří do konkrétního obchodního procesu, a proto ji lze znovu použít k automatizaci více obchodních procesů
  2. ^ „Služby“. Archivovány od originál dne 2012-05-01. Citováno 2010-03-09.
  3. ^ Typ funkčnosti poskytované službou.
  4. ^ Kanu Tripathi.Zpracování transakcí se službou bez WS-AtomicTransaction [Online]. Datum přístupu: 25. dubna 2010.
  5. ^ Služby, které obsahují agnostickou logiku
  6. ^ Dennis Wisnosky.Principy a vzorce na americkém ministerstvu obrany Archivováno 2010-09-20 na Wayback Machine [Online]. Datum přístupu: 25. dubna 2010.
  7. ^ Matthew Dailey.Architektury zaměřené na návrh softwarové architektury (část II) Archivováno 2011-07-24 na Wayback Machine [Online]. Datum přístupu: 25. dubna 2010.
  8. ^ Vzor centralizace metadat
  9. ^ Vzor centralizace smlouvy
  10. ^ Oficiální vzor koncového bodu

externí odkazy