Conway's Law a Team Topologies: týmy kolem kontextů

0:00 – přehrát od tohoto místa Tři týmy, tři sprinty, jeden požadavek

Modelová firma má frontend tým, backend tým a DBA tým. Jeden doménový požadavek u ní projde všemi třemi týmy a třemi sprinty.

Kód za to nemůže. Příčina je v tom, kdo s kým ve firmě mluví, a popsal ji Melvin Conway už v roce 1968.

0:30 – přehrát od tohoto místa Conway’s Law

Conway to v časopise Datamation napsal zhruba takhle. Organizace, které navrhují systémy, nakonec dojdou k návrhu, který kopíruje jejich komunikační strukturu.

Každému týmu odpovídá kus systému. Rozhraní mezi moduly tak vlastně zapisuje dohodu dvou skupin lidí. Pozor, jde o skutečnou komunikaci a organizační diagram s ní sedět nemusí. Rozhoduje, kdo s kým denně řeší práci.

Kniha to ukazuje na třech případech. Týmy rozdělené podle vrstev vyrobí vrstvenou architekturu. Když stejné lidi přeskupíte na Catalog, Ordering, Billing a Warehouse, vzniknou čtyři moduly nebo služby, pro každý kontext jeden.

A tým bez vnitřních hranic, kde všichni sahají do všeho, vyrobí Big Ball of Mud.

Slovo zákon je trochu silné, jde spíš o tendenci. Kdo spolu denně mluví, domluví se přímo. Kde se nemluví, nastoupí rozhraní a to časem ztuhne. Obejít se to dá, jen když se o to vědomě snažíte.

1:47 – přehrát od tohoto místa Bounded Context = týmová hranice

Vaughn Vernon doporučuje, aby každý Bounded Context patřil jedinému týmu. Obráceně to jde, jeden tým klidně vlastní víc kontextů.

Vernon to nepodává jako zákon, spíš jako preferenci. Lidé z týmu můžou vypomáhat jinde a kontext vlastní tým jako celek.

Když se o jeden kontext dělí dva týmy, uvnitř buď vznikne neoficiální hranice, nebo ho nevlastní nikdo. Sdílený kontext proto má být jen dočasný stav s koncovým datem.

Vlastnictví se dá ověřit. Položte vedle sebe mapu týmů a mapu kontextů. Kontext, ke kterému neumíte přiřadit tým, co ho nasazuje a drží u něj pohotovost, je fikce.

V repozitáři má ten test strojovou podobu. Každý adresář kontextu má pravidlo v souboru CODEOWNERS. Co v něm chybí, nemá vlastníka, ať se na poradách tvrdí cokoli.

2:56 – přehrát od tohoto místa Čtyři typy týmů

Slovník pro návrh týmů dodali Matthew Skelton a Manuel Pais. Jejich kniha Team Topologies vyšla v roce 2019 a rozlišuje čtyři typy týmů.

Stream-aligned tým vlastní celý tok hodnoty od zadání až po provoz, typicky jeden kontext. Mívá pět až devět lidí. Ve zdravé organizaci je takových týmů většina.

Platform tým dodává self-service platformu. Stream-aligned tým si databázi naklikne sám v portálu, místo aby psal žádost a týden čekal.

Platforma má být jen tak tlustá, jak je nutné. Autoři tomu říkají Thinnest Viable Platform. Nejtenčí verzí je klidně wiki stránka se seznamem schválených služeb.

Enabling tým pomáhá ostatním osvojit si novou techniku, třeba CQRS. Pak odejde k dalšímu týmu. Časově omezená je jen ta spolupráce a o jejím konci se rozhodne hned na začátku.

A complicated-subsystem tým drží algoritmicky náročnou část domény, třeba risk engine nebo ML model. Důvodem je specializace, na kterou by stream-aligned tým bez vlastních specialistů nestačil.

Na subdomény z druhého dílu to sedí přímo. Core dostane nejlepší stream-aligned tým. Supporting má taky stream-aligned tým, často společný pro dva takové kontexty. A Generic vlastní tým nemá, hotové řešení integruje platforma.

4:44 – přehrát od tohoto místa Tři interakční módy

K typům týmů přidávají autoři tři módy spolupráce. Collaboration znamená, že dva týmy řeší problém společně a intenzivně. Je to produktivní, ale drahé, a proto časově omezené.

U X-as-a-Service jeden tým používá službu druhého přes stabilní API jako černou skříňku. Ve zralé organizaci tak funguje většina vztahů.

Facilitating je způsob, jakým pracuje Enabling tým. Trvá týdny až měsíce a konec se dohodne na začátku.

S Context Mapou se módy překrývají jen zhruba. Collaboration odpovídá Partnershipu nebo Shared Kernelu, X-as-a-Service vztahu Customer Supplier nebo Open Host Service. Patologii jako Big Ball of Mud ale pojmenuje jen Context Map.

Hlavní pravidlo zní takhle. Každá interakce dvou týmů je výslovně jedním z těch tří módů. Neformální vztah nemá kontrakt, Conwayův zákon ho ale do kódu otiskne stejně. Vznikne sdílená třída nebo společné schéma databáze, na které se pak nikdo neodváží sáhnout.

6:06 – přehrát od tohoto místa Otázky a shrnutí

Krátká otázka na rozmyšlenou. Firma sestaví tým z nejseniornějších lidí, co má. Je to complicated-subsystem tým?

Jen tím ne. Complicated-subsystem tým vzniká kvůli specializaci, na kterou stream-aligned tým nestačí. Seniorní obsazení samo o sobě důvod není.

A jedna ze třetího dílu o Context Mappingu. Čím se liší Conformist od vztahu Customer Supplier?

U Customer Supplier má downstream hlas a může žádat změny. Conformist vliv nemá, model upstreamu přebírá tak, jak je.

Takže v kostce. Architektura kopíruje, kdo s kým ve firmě skutečně mluví.

Každý Bounded Context má mít jednoho vlastníka. Ověříte to v CODEOWNERS a podle toho, kdo drží pohotovost. Čtyři typy týmů a tři módy pak dávají slovník, jak týmy kolem kontextů navrhnout.

Příští díl je o Inverse Conway Maneuveru a kognitivní zátěži, tedy o tom, jak strukturu týmů vědomě změnit. Celou kapitolu najdete v knize na ddd-v-symfony.katuscak.cz.