růst microservice přijetí způsobil oživení v popularitě některých dříve přehlížena software návrhové vzory. Mnoho z těchto vzorů bylo získáno z návrhu řízeného doménou Erica Evanse, knihy, která je stejně tak o struktuře týmu, jako o softwarové architektuře.

a z těchto vzorců je možná nejdůležitější pochopit ohraničený kontext. Jako inženýři jsme začali považovat ohraničený kontext za vzor návrhu softwarové architektury. Ale to proto, že jsme to trochu kooptovali z původního použití. Jak používá Evans, ohraničený kontext je stejně organizačním vzorem jako technickým.

proto jsem přišel k pohledu na ohraničený kontextový vzor jako lynchpin v porozumění mikroservisům. Nejen, jak je budovat, ale opravdu proč je stavíme na prvním místě, a jak mohou učinit naše organizace úspěšnějšími. Pokud pochopíme, co jsou ohraničené kontexty-pokud přijmeme ohraničené kontextové myšlení technicky i organizačně — pak můžeme být skutečně úspěšní při budování naší architektury mikroservisů.

proč přejít na mikroslužby?

Chcete-li začít, proveďte trochu cvičení. Zeptejte se sami sebe na tuto otázku: Proč vůbec stavíme mikroslužby?

chvilku se nad tím zamyslete. Jaké jsou výhody, které vám nejprve přijdou na mysl? Jaké jsou hlavní problémy, které bychom měli doufat, že vyřešíme? Zapište si několik odpovědí, jen abyste byli upřímní.

…

máte odpověď? Dobré. Přečtěte si to zpět pro sebe. Trefili jste standardní technické výhody? Nepřetržité doručování, škálovatelnost, polyglot prostředí, kontejnery a mraky, a všechny ty dobré věci? Velký.

ale obsahovala vaše nejlepší odpověď něco o tom, jak umožnit vaší organizaci pracovat efektivněji? Mělo by. Protože budování mikroservisů není o realizaci technických výhod. Ve skutečnosti jde o získání organizačních výhod. Všechno ostatní je detail implementace.

monolity = spřažený kód a spřažené týmy

jak se naše monolity zvětšují a zvětšují, Produktivita začíná klesat. Existují pro to nejméně dva hlavní důvody.

Uvedení brzdy na naše rychlost.

za Prvé, každý technický tým je přispět do jedné obří codebase. Týmy proto čelí stále rostoucí pravděpodobnosti, že jejich kód bude v rozporu s kódem ostatních. Abychom pomohli zmírnit potenciální problémy, které by to mohlo způsobit, zavádíme postupy-zmrazení kódu — testovací období QA, uvolnění vlaků, atd. – které jsou doslova navrženy tak, aby zpomalily naši produktivitu.

tyto postupy samozřejmě zabraňují včasnému nasazení funkcí a vylepšení. Také způsobují zmatek ve schopnosti inženýrů soustředit se na priority svých týmů. Pokud je chyba nalezena během testovacího období, musí odpovědný tým změnit kontext a zaměřit se na vyřešení této chyby. Pokud je ve výrobě nalezena závažná chyba, tým musí chybu nejen opravit, ale také přeskočit obruče, aby ji nasadil další vlak vydání.

On-call povinnost se stává boondoggle. Pokud se s naším monolitem něco pokazí, někdo musí být k dispozici — ve dne nebo v noci — k vyřešení problému. Ale kdo? Velké organizace s velkými monolity jsou obecně potýkají s dvě možnosti:

• incident-řízení týmu, jehož jediným, smutné, je mi líto práci v rámci organizace je reagovat na problémy způsobené jinými inženýry kód, a zjistit, jak je řešit.
• rotující na volání plán, přičemž každý týden nějaké svévolné inženýr je přiřazen smutné, omlouvám se práce stává zodpovědný za řešení problémů, které jsou s největší pravděpodobností způsobeno tím, že kód napsaný nějaký jiný konstruktér, v některých jiných inženýrství týmu.

(Mis)organizování našich týmů

Monoliths si s našimi organizacemi pohrává ještě jiným způsobem. Celá naše organizace pracuje na stejném velkém produktu. Pořád ale musíme rozdělit organizaci na zvládnutelné týmy. Takže máme tendenci hledat funkční role, abychom našli hranice týmu:

Bohužel, tento druh organizační struktury limity společné práce. Spíše než spolupracovat na řešení skutečného problému (např. jak navrhujeme, stavíme a udržujeme funkci X?) členové různých funkčních oblastí se jednoduše soustředí na svou vlastní část, metaforicky házejí svou práci přes plot, když jsou hotovi. Potenciál spolupráce a synergie – kde kombinovaná kvalita úsilí týmu je mnohem větší než součet jednotlivých členů týmu-je ztracen.

je také plná úzkých míst. Když organizujeme naše týmy podle funkční oblasti, pak budeme mít přirozeně nesoulad v prioritách. Řekněme, že tým pro správu produktů se rozhodl, že proces pokladny našeho monolithu musí být přepracován. Naplánují si čas s designovým týmem, aby sestavili nějaké posměšky. V určitém okamžiku budou posměšky dokončeny a předány frontendovému týmu k implementaci. Frontendový tým bude samozřejmě potřebovat API implementovaná backendovým týmem, takže budou blokována, dokud nebude dokončena. Jakmile backendový tým upřednostňuje svou práci na nových pokladních službách, zjistí, že potřebuje pomoc od týmu správy databází (DBA). Což má samozřejmě své priority. Takže backendový tým bude blokován, dokud nebude uvolněna DBA.

způsobem, tato organizační struktura se zdá trochu jako špatně navržen, příliš spolu softwarové architektury… ne?

Microservices = oddělený kód, oddělené týmy

naproti tomu Architektura mikroslužeb umožňuje autonomii týmu. Je mnohem snazší vytvářet týmy, které jsou samostatné, které pracují efektivně společně a které nejsou neustále blokovány závislostmi na jiných týmech.

týmy mohou převzít plnou odpovědnost za svou práci, od návrhu přes vývoj až po nasazení. Každý člen sdílí odpovědnost za dosažení cíle svého týmu, takže jsou motivováni k účasti na více než jen „jejich části“. Pracoval jsem s týmy, kde produktoví manažeři, návrháři, front-end, back-end a mobilní technici mají dohromady na design vlastnosti produktu, čímž se získá daleko lepší výsledky, než by bylo dosaženo tím, že jeden člověk.

tým získává odpovědnost za své vlastní artefakty, jakmile jsou nasazeny do výroby. To obecně vede k vyšší kvalitě kódu, který je snazší řešení problémů. Proč? Na rozdíl od monolitu mají týmy tendenci mít holistický pohled na mikroservisy, které vlastní. Takže je mnohem jednodušší pro tým předvídat problémy, přidat dobré logování a metriky řešit problémy, když nastanou, a aby se správné použití odolnost vzory (např. opakování, jističe a zálohy, apod.), které pomohou vyhnout se problémům v první řadě.

Navíc, protože týmy mají plný smysl pro vlastnictví nad jejich prací, udržováním jejich služby zdravé a běží ve výrobě se stává méně o děsivé plán vydání, a více o rozvíjení jejich vytvoření.

konečně týmy pracují na stejném cíli, na stejné časové ose. To znamená, že už nemusíte blokovat jednu osobu, protože čekají, až se někdo v jiné funkční oblasti uvolní.

musíme být úmyslní ohledně autonomie

ale tyto výhody nedostáváme zdarma pouhým rozbitím našeho monolitu na mikroservisy. Pojďme se podívat na naše první, naivní pohled na microservices architektury:

Pokud se budeme stejně jako většina inženýrů naše počáteční představa microservice architektura je, no, pár microservices. Každý vystavuje nějaký druh API (možná ReST), aby z něj mohla číst a zapisovat jakákoli jiná služba.

jak získáváme zkušenosti, dozvídáme se, že ne všechny mikroservisy slouží stejnému účelu — nebo by alespoň neměly. A proto, stejně jako naše monolit byly uspořádány ve vrstvách, takže jsme uspořádat náš microservices:

V tomto bodě, definovali jsme různé typy microservices a aplikace, které chceme budovat. Velký. Ale stále jsme neudělali velký pokrok, pokud jde o autonomii týmu. Každá mikroservis bude muset být vlastněna nějakým týmem. A tak vyvstává otázka: které týmy budou vlastnit které mikroslužby?

Cross funkční týmy

Naše první, naivní přístup by mohl být organizovat naše týmy napodobováním naše monolit org strukturu:

Tady vidíme týmy (ve fialové) pořádá funkce: UX design, frontend inženýrství, backend inženýrství, datové inženýry, Dba, QA, atd.

To by mohlo být správné, alespoň zpočátku. Ale vraťme se o krok zpět a podívejme se na hodnotu, kterou se snažíme našim zákazníkům přinést. Je naším cílem stavět věci jako následující pro naše zákazníky?

• banda databázových schémat
• banda maket uživatelského rozhraní
• banda mikroservisů, které mohou mluvit s databází MySQL?

ne tak docela. To jsou jen nástroje, pomocí kterých vytváříme hodnotu pro naše zákazníky. Skutečná hodnota, kterou poskytujeme našim zákazníkům / uživatelům, přichází ve formě funkcí a funkcí, jako jsou:

• produktový katalog pro vyhledávání
• mechanismus pro místo položky v nákupním košíku a následně si je zakoupit
• oznamovací systém, aby upozornil zákazníky o stavu jejich nákupu

Podobně, nechceme organizovat náš tým do funkční oblasti. Spíše bychom měli definovat naše týmy podle hodnoty, kterou vytvářejí pro zákazníky; to znamená napříč funkcemi, v (příhodně pojmenovaných) mezi funkčními týmy.

s křížovými funkčními týmy každý pracuje společně na vytvoření konkrétního produktu nebo funkce od začátku do konce. Všichni v týmu mají stejné cíle a priority, takže žádná funkční oblast není blokována jinou. Vyžaduje nová služba backend API nějakou práci s návrhem databáze? Pokuta; backendový inženýr týmu i DBA mohou upřednostňovat svou práci společně.

napříč funkčními týmy v nejlepším případě povzbuzují členy ke spolupráci v každé fázi projektu. Každý člen týmu přispívá k celkovému designu funkce. Frontend, backend a mobilní inženýři společně definují smlouvy API. Všichni testují. A každý se začíná dobře orientovat ve své konkrétní oblasti.

A tak, náš tým struktur může začít hledat něco jako tohle:

už je to lepší. Ale pořád mi něco nesedí.

jistě, vytvořili jsme týmy, které pravděpodobně budou efektivnější ve vlastnictví produktů. Ale stále jsme zvolili přístup shora dolů, abychom identifikovali topologii mikroservisů, které naše organizace hodlá vybudovat. Zbývá nám velká sbírka vzájemně závislých mikroservisů, z nichž většina je spojena dohromady. Jednoduše jsme je přidělili různým týmům, které mají stavět.

to vede k obavám, jako jsou:

• jak můžeme vytvořit API, která splní všechny současné a budoucí potřeby, které může mít každý klient? Můžeme zapouzdřit naše data, když některá z našich služeb může být volána službami jiného týmu?
• kolik času strávíme čekáním na implementaci našich závislostí jinými týmy?
• jaké poruchy našich systémů mohou být způsobeny poruchami v jiných systémech(kaskádové poruchy)?
• můžeme kontrolovat počet hovorů, kterých se naše služby mohou účastnit? Můžeme zajistit, že naše organizace nemá vítr vytváří nekonečné synchronní volání mezi služby, vedoucí k astronomické odezvy, nebo horší (a ano, viděl jsem to stalo) nekonečně rekurzivní volání přes služby?
• co když specifická funkce nebo problémový prostor našeho týmu není vhodný pro předem plánovanou topologii mikroslužeb?

potřebujeme ještě jiný způsob myšlení. Možná už existuje vzorec, který bychom měli následovat?

Zadejte Ohraničené Kontextu

Ohraničený Kontext je klíčový design, vzor nese domény řízený design, nebo DDD. Pochopení ohraničeného kontextu nám pomáhá vytvářet autonomní týmy a, rozšířením, autonomní architektury mikroslužeb.

DDD sám popisuje metodiku vývoje softwaru, ve které jedinci v rámci organizace spolupracovat definovat společný jazyk. Ve své knize Domény Řízený Design, Eric Evans často líčí inženýři, kteří pracují s produktem majitelé stanovit dohodnuté slovní zásoba k popisu věcí, jako jsou výrobky, součástky, výrobky, činnosti, že výrobek může provádět (nebo může být provedena na výrobku), části pracovní postupy, atd. Tato slovní zásoba zahrnuje doménu organizace.

v mnoha velkých organizacích se však definování jediné konzistentní slovní zásoby stává neproveditelným. V těchto případech rozdělujeme naši doménu na subdomény. Příklady subdomén mohou zahrnovat:

• řízení Zásob
• Výrobek objev
• Cílem managementu
• Nákupní vozíky a pokladny

Jako projektanti, konstruktéři, produktoví manažeři, atd, dát dohromady, aby postavit se na subdomény, které tvoří svůj vlastní způsob myšlení a mluví o subdoménu a jeho složek.

to je místo, kde DDD splňuje cross-funkční strukturu týmu. Ačkoli členové týmu jsou z různých funkčních oblastí, jsou zodpovědní za svou vlastní subdoménu, nakonec se stanou rezidentními odborníky. Navíc, tým je zodpovědný za určování artefaktů — microservices, webové aplikace, mobilní aplikace, databáze a související infrastruktury — jsou zapotřebí k vytvoření subdomény k životu, a organizace zákazníci.

tým a jeho artefakty můžeme považovat za ohraničený kontext.

definování ohraničeného kontextu

zatímco Evans ve své knize často diskutuje o ohraničených kontextech, ve skutečnosti vzorec explicitně nedefinuje. Pokusím se to udělat zde:

ohraničený kontext:

vnitřně konzistentní systém s pečlivě navrženými hranicemi, které zprostředkovávají, co může vstoupit do systému a co ho může opustit.

jinými slovy, Ohraničené Kontextu představuje kontext — v podstatě, systém, který zahrnuje družstva, komponenty — s jasně definovanými hranicemi, které upravují, co může vstoupit do systému, a to, co můžete ukončit to.

Buňky (ty malé věci, které dohromady tvoří všechny živé bytosti) nabízíme pěkný přirovnání. V buňce jsou všechny druhy složek (jádro, ribozomy, cytoplazma, cytoskeletony atd.), které jsou zapouzdřeny v samotné buňce. Obklopující každou buňku je však membrána, která působí jako bariéra mezi vnitřními buňkami buňky a zbytkem organismu. Membrána chrání buňku před jejím prostředím, umožňuje do ní vstupovat specifické živiny a umožňuje odchod různých vedlejších produktů.

ve stejném duchu se ohraničený kontext skládá z různých komponent (mikroservisy, webové aplikace, mobilní aplikace,databáze, fronty zpráv atd.). Slouží také jako logická bariéra, která tyto komponenty zapouzdřuje. Interně mohou být komponenty spojeny a mohou si navzájem volně předávat data. Ohraničený kontext však pomáhá externě vynutit volné spojení, definování explicitních bodů, kde:

• externí data můžete zadat (možná prostřednictvím spotřebitelských objednání Kafka téma)
• vnitřní data mohou opustit (možná přes jiný Kafka téma, nebo prostřednictvím dobře-design API, pečlivě vytvořený, aby skrýt všechny vnitřní systém informací)

Ohraničené Kontextu představuje jeho cross-funkční tým. Tým se skládá z různých členů týmu (projektanti, frontend/backend/mobilní inženýři, produktoví manažeři, data inženýrů a QA inženýři, atd.). Interně, tito členové spolupracují na dosažení stejných konzistentních cílů. Navíc tito členové týmu jsou (nebo by měli být) zapouzdřeni tak, aby měli minimální závislost na jiných týmech.

spíše než začínat na organizační úrovni a definování všech aplikací a microservices očekáváme, že stavět, budeme stavět týmy kolem našich subdomén, což tyto týmy, aby růst jejich subdomén a definujte, co musí být postavena. Provedeno správně, máme tendenci vidět různé ohraničené kontexty v organizaci jako organicky rostoucí, spíše než jako rigidní, předdefinované struktury.

Dopady na rozbití monolitu

conwayův Zákon nám říká, že organizace design softwarových systémů, které napodobují jejich organizace komunikační struktury. To se často ukazuje jako pravda, takže bychom měli být přemýšliví o tom, jak strukturujeme naši organizaci, když začneme budovat mikroservisy.

nyní by se ve vaší mysli měl objevit obrázek. Když přecházíme od monolitu k mikroservisům, měli bychom začít přemýšlet svisle (dělení monolitu jeho subdoménami) místo vodorovně (dělení monolitu jeho funkčními vrstvami).

jinými slovy, neměli bychom začít tím, že nahradí monolit dat přístup vrstva s daty microservices. Spíše bychom měli začít rozdělením celé funkce(například procesu pokladny nebo snad vyhledávání produktů). Každá funkce bude představovat ohraničený kontext. A každý bude rozdělen specializovaným cross-funkčním týmem.

kromě toho, že tým by se měl soustředit na svůj úkol, na dosah ruky, která je buď:

• věrně replikovat existující funkce,
• nebo (lépe) vybudovat nový, lepší zážitek pro své zákazníky.

v rámci procesu by měl tým navrhnout systém, který je pro toto úsilí nejvhodnější.

můžeme se například rozhodnout, že z monolitu odstraníme funkci vyhledávání produktů. Tým pro vyhledávání produktů může nakonec navrhnout systém, který zahrnuje:

• Kafka spotřebitelé, kteří poslouchají řadu externích témat Kafka aktualizovat svůj vlastní interní systém záznamu (SoR) pro produkty.
• Kafka vydavatele, který tlačí změny v jeho SoR na vnitřní Kafka téma
• další Kafka spotřebitele, že poslouchá, že vnitřní tématu a aktualizace Elastický index Vyhledávání
• GraphQL koncového bodu pro volné vyhledávání, které dotazy Elastické Vyhledávání
• Zbytek koncového bodu, který načítá jednotlivé produkty podle ID
• přepracované webové aplikace, která používá ty sledované vlastnosti, umožnit zákazníkům vyhledávat produkty a prozkoumat podrobnosti o produktu
• podobnou sadu obrazovek v našich mobilních aplikací, které používají tyto koncové body
• Kafka vydavatele, který tlačí zprávy, zastupující různé dotazy provedené zákazníky, aby externí Kafka téma, pro všechny ostatní ohraničené kontextu (řekněme, analytics) že by mohl být zájem

jakmile začneme odlupuje více a více vertikální části našeho monolit, ostatní týmy budovat své vlastní Ohraničené Souvislostech. Tyto ohraničené kontexty by mohly vypadat docela odlišně od sebe navzájem.

Všimněte si, že komponenty v dané Ohraničené Kontextu by mohl být pevně spojen; nicméně, jsme se udržet naše Ohraničené Souvislostech, oddělené od sebe navzájem. V našem příkladu se jakákoli komunikace mezi ohraničenými kontexty děje předáváním zpráv prostřednictvím fronty zpráv Kafka. Důležité je, že se vyhýbáme synchronním voláním požadavků/odpovědí mezi ohraničenými kontexty.

to platí i pro to, co zbylo z monolitu. Rozhodně nechceme těsné spojení mezi našimi novými mikroslužbami a naším starším monolitem. Takže když odlupujeme části monolitu pryč, využíváme předávání zpráv, abychom umožnili zbývajícím částem komunikovat s našimi novými ohraničenými kontexty.

kontrola Reality na všech těchto odděleních

v tomto bodě si můžeme položit otázku, zda je skutečně možné udržet naše ohraničené kontexty oddělené.

v reálném světě, můžeme opravdu udržet naše týmy chráněny před vnějšími závislostmi? Nikdy nebudou případy, kdy tým musí být zablokován jiným týmem, aby mohl svou práci dokončit?

a můžeme skutečně vytvořit architektury služeb pro naše subdomény, které jsou zcela odděleny od ostatních subdomén? Opravdu není potřeba, aby aplikace v jednom ohraničeném kontextu někdy synchronně volala službu v jiném?

ve skutečnosti by mohlo být nemožné udržet naše ohraničené kontexty 100% oddělené. Ale můžeme se dostat blíž, mnohem blíž, než si většina z nás může myslet.

reálné architektury

Začněme tím, že se podíváme na oddělené architektury. Často jsme se koupit do omylu, že daný typ dat by měl žít přesně v jednom místě, a že žádný jiný systém, musí volat přímo do jednoho místa pro přístup k datům.

označujeme to jako přiřazení jediného zdroje pravdy (SSoT) k našim datům. Ale jak je popsáno v tomto článku, který rozebírá myšlenku SSoTs, tento pojem je, z velké části, anti-vzor. Místo toho by většina ohraničených kontextů měla ukládat vlastní místní kopii všech dat, která potřebují použít.

to dokládá náš kontext ohraničený vyhledáváním produktů z předchozí části. Tento ohraničený kontext se samozřejmě silně spoléhá na data katalogu produktů naší organizace. Ale je pravděpodobné, že data jsou generována v jiném ohraničeném kontextu (budeme to nazývat ohraničeným kontextem produktu).

první Naše (naivní) přístup by mohl být vystavit ReST API z Produktu-Vstup Ohraničený Kontext a účinnost služeb v rámci Produktu-Vyhledávání Ohraničený Kontext volání rozhraní API. Ale můžeme to udělat lépe. Místo toho můžeme systémy oddělit zveřejněním změn provedených službami pro vstup produktů na Kafku. Náš produkt-Search Kafka spotřebitelé pak vyzvednout tyto zprávy a aktualizovat databáze vyhledávání produktů.

Všimněte si, že ty dvě Ohraničené Kontexty jsou nakonec-konzistentní. To znamená, že budou krátká časová období, kdy daná data mohou být nekonzistentní mezi vstupem produktu a vyhledáváním produktu. Například pokud se cena widgetů White Wombat zvýší z 1,99 na 2$.49, tam bude krátké časové období(často otázkou sekund, ne-li milisekund), kde je 50¢ rozdíl v bílé Wombat Widget cena přes dva ohraničené kontexty.

to vede k případům v reálném světě, kdy nemáme jinou možnost než pár ohraničených kontextů. V některých případech není případná konzistence přijatelná. Například, než zákazník může dokončit svůj online nákup, možná budeme muset zajistit, aby každá položka v nákupním košíku byla ve skutečnosti k dispozici v daném okamžiku. I tehdy můžeme často minimalizovat vazbu mezi dvěma ohraničenými kontexty.

Naše interakce může vypadat například takto:

• Jak zákazník používá Produkt-Vyhledávání, UI najít produkty, Produkt-Vyhledávání databází se používá k načtení informací (jako jsou styly, hodnocení zákazníků, ceny, atd.) o produktech
• i když zákazník zahájí proces pokladny, stále používáme databáze vyhledávání produktů k načtení informací, které je třeba zobrazit.
• Nakonec, když zákazník klikne na to závěrečné „Dokončit Nákup“ tlačítko, uděláme jeden, synchronní volání k Produktu-Vstup Ohraničené Souvislosti ověřit položky dostupnost před dokončením nákupu.

další běžný příklad, který vyžaduje okamžitou konzistenci související s autorizací. V mnoha systémech musí být bezpečnostní tokeny načteny nebo ověřeny na každém požadavku. V těchto případech, pravděpodobně musíme dovolit, aby naše ohraničené kontexty nazývaly jiný, ohraničený kontext orientovaný na bezpečnost.

real-life orgists

a co samostatné, cross-funkční týmy? Jak je to možné v reálném světě?

ve skutečnosti je to proces neustálého pohybu směrem k zcela samostatným týmům. Zřídka dosáhneme 100% autonomie s našimi týmy. Pokud však začneme inteligentním uspořádáním našich týmů a rozpoznáme a reagujeme na vzniklá úzká místa,můžeme se přiblížit.

pro začátek bychom měli maximalizovat naše vertikální, cross-funkční týmy a minimalizovat počet horizontálních, single-funkční týmy. „Jádrové“ týmy – jejichž posláním je budovat společné datové služby, které spotřebovávají jiné týmy zaměřené na produkty-a místo toho formovat naše týmy kolem obchodní hodnoty, kterou poskytnou.

mnoho organizací se k tomuto cíli přibližuje, nejprve tvoří týmy produktových manažerů orientované na doménu a front-end a back-end inženýrů. To je začátek. Ale kdo jiný by měl tyto týmy zahrnovat? Přesné členství se může lišit v různých týmech s různými potřebami. Ale měli bychom zvážit věci jako:

• pokud má náš tým přední inženýry, pak je pravděpodobné, že by měli úzce spolupracovat s grafickým designérem, který se věnuje této doméně.
• mobilní inženýři-často odděleni do své vlastní oblasti org-by měli být zahrnuti pro domény s mobilní komponentou.
• V ní poučný článek o datové sítě, Zhamak Dehghani stěžuje, že data inženýři jsou často vyloučeny z kříž-funkční týmy — na úkor datových inženýrů, a cross-funkční týmy samy.

jakmile určíme členství v našich týmech, měli bychom si dát pozor na úzká místa. Existují nějaké další týmy, které obvykle blokují produktivitu našich napříč funkčními týmy?

mnoho organizací má například specializovaný bezpečnostní tým. To je samozřejmě dobrá praxe; organizace potřebují soudržnou bezpečnostní strategii a způsob, jak zajistit správu nad touto strategií. Je však také běžné, že týmy zastaví svou práci v různých fázích, aby umožnily bezpečnostní kontroly své práce. I v těch nejlepších situacích to vytváří zátarasy pro naše týmy jako rutinní obchodní praxi. Navíc to často povede k tomu, že týmy budou muset zrušit celou nebo část své práce a začít znovu, protože odhalí bezpečnostní požadavky, které nebyly splněny.

to je zjevně špatný zápach. Jak ale můžeme prosadit bezpečnostní standardy naší organizace a zároveň umožnit týmům zůstat autonomní a produktivní?

můžeme to udělat přidáním bezpečnostních inženýrů do našich vzájemně funkčních týmů. Můžeme použít tři přístupy:

• Pokud máme to štěstí, že mají poměrně velký bezpečnostní tým, můžeme přiřadit každému cross-funkční tým full-time bezpečnostní inženýr (SE).
• s menšími bezpečnostními týmy může být každé SE přiděleno několika mezi funkčními týmy na částečný úvazek. To umožní stále SEs pochopit týmy, cíle a vzory, a pracovat s týmem dodržovat org bezpečnostních norem v celém procesu.
• Pokud nemáme dostatek bezpečnostních prostředků, můžeme se pohybovat opačným směrem. Spíše než přivést členy bezpečnostního týmu do našich cross-funkčních týmů, můžeme přivést členy cross-funkčních týmů do bezpečnostního týmu. Každý křížově funkční tým by určil jednoho nebo dva zástupce bezpečnosti. Zástupci by se pravidelně setkávali s bezpečností a drželi krok s bezpečnostními požadavky a standardy organizace. Nemusí to být sami bezpečnostní experti. Budou však moci sloužit jako bezpečnostní inženýr a zajistit, aby jejich týmy dodržovaly bezpečnostní postupy organizace.

cechy

to zapadá do jiného organizačního vzorce, který získává trakci: cechy. Model cechu se zrodil z modelu cross-functional team. Ze své podstaty, tyto týmy jsou naplněny členy, kteří se specializují na různé funkce. Dosud, často má smysl, aby se lidé, kteří se specializují na konkrétní funkci, setkali společně; například, na:

• Zdokonalit své dovednosti a učit se od sebe navzájem
• Zjistit a stanovit osvědčené postupy pro jejich konkrétní funkce
• v Závislosti na funkci, vytvořit společnost, normy a požadavky

Naše poslední bezpečnostní řešení efektivně tvořil „bezpečnostní cech“. Členové týmu primárně pracovali se svými vertikálními týmy; ale pravidelně, někteří z nich se setkali s bezpečnostním „Cechem“, aby diskutovali o bezpečnostních postupech a standardech organizace.

MODEL cechu také funguje zvláště dobře, pokud jde o softwarovou architekturu. Zejména s architekturou mikroservisů je vyžadována určitá úroveň technického řízení v celé organizaci. Přesto mít skupinu architektů, kteří sedí v metaforické slonovinové věži a rozdávají týmům pravidla, je obecně kontraproduktivní. Místo toho se vedoucí / vedoucí inženýři z našich napříč funkčními týmy mohou pravidelně setkávat v architektonickém cechu. Tam, mohou vznést problémy ze svých týmů, a vypracovat řešení, a stanovit patty a standardy.

Cechy může být také rozšířena na téměř všechny ostatní funkce stejně. Po všem, chceme, aby se designéři vyvíjeli, a pracovat od, společný průvodce stylem uživatelského rozhraní. Chceme, aby naši frontendoví inženýři používali stejné prvky uživatelského rozhraní. Inženýři QA by měli být v souladu s tím, jak se testování provádí v našich organizacích. A produktoví manažeři by měli být synchronizováni s celkovým plánem produktu organizace.

spojte to vše

přechod na mikroslužby může dramaticky zvýšit produktivitu našich týmů. Musíme však pochopit, jak využít architektury mikroslužeb, abychom se tam dostali. Ze všech návrhových vzorů a konceptů, které se týkají mikroservisů, je ohraničený kontext pravděpodobně tím nejdůležitějším, který nám dává toto porozumění.

s pevným uchopením ohraničeného kontextu chápeme, že:

• Naši organizační strukturu a naše technická architektura jdou ruku v ruce
• Náš produkt-orientované týmy by měly mít minimální závislostí na jiné týmy, stejně jako systémy budují by měla být oddělena od jiných systémů

obecně platí, zahrnující Ohraničené Souvislosti klade v myšlení, že musíme být úspěšní s naším microservices architektury. Než se vydáte na cestu microservices, ujistěte se, že rozumíte tomuto důležitému vzoru!