Conway's Law a Team Topologies

05.01 Conway's Law – gravitační zákon softwarové architektury

V dubnu 1968 vyšel v časopise Datamation krátký esej Melvina Conwaye s názvem How Do Committees Invent? [1]. Conway v něm formuloval pozorování, které se později stalo známé jako Conway's Law:

„Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.“

V překladu: jakákoli organizace, která navrhuje systém, vytvoří takový design, jehož struktura kopíruje komunikační strukturu této organizace. Není to architektonická preskripce – je to empirické pozorování. A je to brutálně spolehlivé. Pokud máte oddělený frontend a backend tým, dostanete oddělený frontend a backend v kódu. Pokud máte oddělený DBA tým, dostanete v kódu vrstvu, která jen obsluhuje databázi. Pokud máte jeden tým bez subhraničení, dostanete Big Ball of Mud.

Tři reálné případy Conway's Law v praxi

1. Tým rozdělený podle vrstev → Layered Architecture. Společnost s 30 vývojáři rozdělená na „frontend tým“, „backend tým“ a „DBA tým“ nevyhnutelně vyprodukuje třívrstvou architekturu. Každý tým má vlastní release cyklus, vlastní CI/CD pipeline, vlastní sprint review. Bounded Context se stane v lepším případě interní záležitostí backend týmu – frontend a DBA o něm nevědí. Důsledek: změna jednoho doménového požadavku se obtočí přes všechny tři týmy a tři sprinty.
2. Tým rozdělený podle produktu/streamu → mikroservis nebo modul per BC. Stejná organizace přeorganizovaná na „Catalog tým“, „Ordering tým“, „Billing tým“ a „Identity tým“ – každý tým plně end-to-end (frontend, backend, DB, devops) – přirozeně vyprodukuje 4 mikroservis nebo 4 izolované moduly v monolitu, jeden per Bounded Context. Conway's Law funguje, jen jsme jí dali jiné vstupy.
3. Tým bez interních hranic → Big Ball of Mud. 8 vývojářů, kteří všichni sahají do všeho, nevyprodukují žádné Bounded Contexts. Vyprodukují jeden monolit, ve kterém Customer ve fakturaci je tatáž třída jako Customer v marketingu, jen s víc atributy. Klasický důsledek: po 18 měsících si nikdo netroufne změnit nic, protože „to může mít vliv kdekoli“.

05.02 Bounded Context = týmová hranice

Vaughn Vernon v knize Implementing Domain-Driven Design (2013, kap. 2) [2] formuluje pravidlo, které je možná nejdůležitějším praktickým výstupem celého DDD:

„A Bounded Context should be owned by a single team. The reverse – multiple Bounded Contexts owned by a single team – is sometimes acceptable.“

Pravidlo má dvě části, které se často chybně čtou jako jedno:

• Jeden Bounded Context = jeden tým (vždy). Pokud dva týmy sdílejí jeden BC, Conway's Law okamžitě vstoupí – buď vznikne neoficiální sub-hranice (a tedy fakticky dva BC, ale nikdo to nepřiznal), nebo vznikne sdílené vlastnictví, které znamená, že BC nikdo nevlastní a degraduje na Big Ball of Mud s Shared Kernel režií. Pravidlo: nikdy nesdílejte BC mezi týmy bez explicitního Shared Kernel vztahu – a Shared Kernel sám je drahý vztah, ne default.
• Jeden tým = jeden nebo více Bounded Contexts (povoleno). Malý tým (5–9 lidí) může v pohodě vlastnit 2–3 menší BC. Důvodem k limitu je kognitivní zátěž – viz sekci 05.06. Velký tým, který by vlastnil 5+ BC, je signál, že tým má být rozdělen.

Důsledek je nepříjemný pro mnoho organizací: Context Map a Team Map jsou v ideálním stavu téměř izomorfní. Pokud máte 7 BC a 4 týmy, máte buď mismatch (3 BC nemají vlastníka), nebo jeden tým vlastní 2+ BC (a to musí být vědomé rozhodnutí, ne nedopatření). Detail vztahu mezi Context Map a Team Map je v kapitole o Context Mappingu.

A obráceně: pokud máte 4 BC a 7 týmů, je jasné, že na BC vás ovlivnil někdo, kdo nepoužíval DDD – třeba historická organizační struktura, kterou nikdo neaktualizoval. Zde přichází Inverse Conway Maneuver (sekce 05.05).

Co dělat, když Context Map a Team Map nesedí

V praxi narazíte na 4 typy nesouladu mezi Context Mapem a Team Mapem. Každý vyžaduje jiný typ akce:

Žádný z těchto scénářů není akutní krize – Conway's Law dává systému dostatek setrvačnosti, aby s nesouladem fungoval měsíce. Ale dlouhodobě se nesoulad projeví v rostoucích lead time, rostoucí change failure rate a klesající morálce týmů. Nesoulad je pomalý jed, ne explozivní porucha.

05.03 Team Topologies – 4 typy týmů (Skelton & Pais 2019)

V roce 2019 vydali Matthew Skelton a Manuel Pais knihu Team Topologies: Organizing Business and Technology Teams for Fast Flow [3], která poprvé systematicky popsala, jaké typy týmů má organizace mít a jak mezi sebou mají komunikovat. Nejde o nový framework jako SAFe nebo LeSS – Team Topologies je jazyk, kterým se dá mluvit o organizačním návrhu. A pro DDD je to chybějící doplněk Vernona.

Skelton a Pais identifikovali 4 typy týmů. Cokoliv jiného (klasický „enterprise architecture team“, „QA tým“, „Center of Excellence“) je buď maskovaná varianta jednoho ze 4 typů, nebo organizační anti-vzor.

Stream-aligned team

Vlastník end-to-end value streamu – typicky jeden Bounded Context. Stream-aligned tým má všechny role potřebné k tomu, aby samostatně doručil hodnotu koncovému uživateli: vývojáře (frontend i backend), QA, designéra, někdy product ownera. Tým rozhoduje, doručuje a provozuje v produkci – žádné „předání“ do jiného týmu.

• Velikost: 5–9 lidí (Two-Pizza Rule).
• Vlastnictví: 1 BC (typicky), maximálně 2–3 související malé BC.
• Cíl: minimalizovat kognitivní zátěž a maximalizovat flow hodnoty.
• Měření: DORA metriky (lead time, deployment frequency, change failure rate, MTTR).

Většina týmů v každé zdravé technologické organizaci jsou stream-aligned týmy. Pokud máte 10 týmů a méně než 7 z nich jsou stream-aligned, podíváme se na anti-vzory v sekci 05.08.

Platform team

Poskytuje self-service platformu pro stream-aligned týmy. Platform team vlastní interní vývojářskou platformu (IDP – Internal Developer Platform): CI/CD šablony, observability stack (Prometheus, Grafana, Sentry), Kubernetes, secrets management, šablony pro nové BC, vývojářský portál.

Hlavní atribut Platform teamu je slovo self-service. Stream-aligned tým si na platformu nezadává ticket („potřebuju nový Postgres“) a nečeká týden – naklikne ho sám přes portál nebo nasadí přes IaC modul, který Platform team udržuje. Pokud Platform team funguje jako ticketová fronta, není to Platform team – je to infrastruktura jako bottleneck a anti-vzor (sekce 05.08).

• Velikost: 1 Platform team na 50–150 vývojářů; obvykle 5–9 lidí.
• Měření: NPS od stream-aligned týmů, adoption rate, time-to-first-deploy pro nový BC.
• Anti-charakter: Platform team nesedí na změnách – má roli enabler, ne gatekeeper.

Enabling team

Time-boxed tým specialistů, který pomáhá stream-aligned týmu osvojit si novou techniku nebo technologii. Klasické úkoly: „naučte je TDD“, „zaveďte CQRS“, „pomozte s migrací na K8s“, „rozjeďte s nimi event sourcing“. Enabling team se po předání rozpustí – typicky po 3–6 měsících. Není to permanentní útvar.

Enabling team se snadno zamění s Center of Excellence. Rozdíl je podstatný:

Complicated-subsystem team

Vlastní algoritmicky náročnou doménu, kterou by stream-aligned tým nezvládl bez vyhrazených specialistů. Typické příklady: real-time risk engine v bance, ML scoring model, video transcoder, fyzikální simulátor, kompilátor, kryptografická knihovna. Tým má vysokou koncentraci specializovaných znalostí (PhD v matematice/fyzice/CS, hluboké know-how v doméně), které nelze rozprostřít přes 6 stream-aligned týmů.

• Vznik: jen tehdy, kdy stream-aligned tým objektivně narazí na strop.
• Komunikace: obvykle X-as-a-Service vůči stream-aligned týmům.
• Past: snadno se ze stream-aligned týmu stane „complicated subsystem“ jen proto, že má seniornější obsazení. To není důvod – pravým důvodem je objektivní specializace.

Mapování DDD subdomén na typy týmů

Klasifikace subdomén z kapitoly o subdoménách (Core / Supporting / Generic) přirozeně mapuje na typy týmů:

05.04 Tři interakční módy mezi týmy

Skelton a Pais nedefinovali jen typy týmů, ale i 3 (a jen 3) povolené módy interakce mezi nimi. Cokoliv jiného („tak ti tam někdo pomůže“, „domluvte se nějak“, „pošli ticket a uvidíme“) = neformální vztah, který Conway's Law okamžitě začne tvarovat ad hoc interfacem v kódu.

Collaboration

Dva týmy společně, intenzivně řeší problém. Sdílí backlog, plánují spolu, code-review napříč. Mód je vysoce produktivní, ale drahý – duplikuje meetingy, rozmazává odpovědnost, zatěžuje cognitive load obou týmů. Proto je explicitně časově omezený.

• Kdy: při objevu nového problému (discovery), při zásadním refactoringu, při bootstrapu nového BC.
• Kdy ukončit: jakmile je interface jasný – přejít na X-as-a-Service.
• Mapování na DDD: Partnership / Shared Kernel z Context Mapu.
• Past: permanentní Collaboration → tyto dva týmy mají být jeden tým. Spojte je.

X-as-a-Service

Jeden tým konzumuje druhý jako black-box přes stabilní API/kontrakt. Konzument nezná ani interní strukturu, ani sprint plan poskytovatele – má pouze SLA, dokumentaci a release notes. Toto je výchozí stav většiny mezi-týmových vztahů ve zralé organizaci.

• Mapování na DDD: Customer / Supplier nebo Open Host Service z Context Mapu.
• Měření: SLA, error rate, dostupnost API, breaking-change rate.
• Cíl: minimální komunikace nutná k používání služby. Žádný stand-up napříč týmy.
• Past: X-as-a-Service vyžaduje vyspělé API a versionování – pokud poskytovatel mění API každý sprint, je to faktická Collaboration s falešnou nálepkou.

Facilitating

Enabling team pomáhá stream-aligned týmu osvojit si nové know-how. Mód je dočasný (3–6 měsíců), interaktivní (pair programming, code review, workshopy) a má jasný cíl: stream-aligned tým to bude umět sám. Po dosažení cíle se mód ukončí a Enabling team odejde k jinému stream-aligned týmu.

• Mapování na DDD: nemá přímý ekvivalent v Context Mapu (Context Map řeší vztahy mezi BC, ne dovednosti uvnitř BC).
• Cíl: autonomie stream-aligned týmu po předání.
• Past: Facilitating, který trvá rok+, se z definice mění na Center of Excellence.

05.05 Inverse Conway Maneuver

Conway's Law říká „struktura kopíruje organizaci“. Inverse Conway Maneuver obrací směr: pokud chceme jinou strukturu, MUSÍME nejdřív změnit organizaci. Jinými slovy – místo bojování s Conway's Law ji použijeme jako nástroj.

Inverse Conway Maneuver popsali Skelton a Pais (2019, kap. 3) jako 4-krokový postup, navazující na dřívější Forsgrenův výzkum DORA Accelerate (2018):

1. Definovat cílovou architekturu. Typicky Context Map z DDD – seznam Bounded Contexts a vztahů mezi nimi. Bez tohoto kroku není co kopírovat. Detail v kapitole o Context Mappingu.
2. Spočítat počet stream-aligned týmů. Hrubé pravidlo: 1 BC = 1 tým. Pokud máte 6 BC, potřebujete 6 stream-aligned týmů. Pokud máte aktuálně 3 týmy (frontend, backend, DBA), znamená to reorganizaci na 6 vertikálních týmů – buď z existujících lidí, nebo nábor.
3. Re-org: rozpustit horizontální týmy, poskládat vertikální stream-aligned týmy. Klasický bod, kde implementace selže. Frontendoví lidé nechtějí být „v Catalog týmu“ – chtějí být s ostatními frontend kolegy. Manažeři nechtějí ztratit tým 12 lidí pro tým 7 lidí. Tato fáze potřebuje silnou podporu CTO/VP Engineering.
4. Vyřešit Platform team. Z definice 1 Platform team na celou organizaci (50–150 vývojářů). Vznikne typicky z bývalých „infrastructure“ lidí + 1–2 senior z každého stream-aligned týmu. Cíl: do 6 měsíců self-service IDP.

Skelton a Pais výslovně varují: Inverse Conway Maneuver bez podpory managementu neuspěje. Re-org je politický akt. Pokud CTO řekne „udělejte to, ale beze změny org chartu“, máte před sebou 6 měsíců práce, která nikam nevede – Conway's Law původní org chart vrátí každý refactor.

Praktická past: reorganizace je bolestivá. Lidé ztrácejí seniority, manažeři ztrácejí pravomoci, domácí kultury týmů (frontend kávovar, backend stand-up) se rozbijí. Pokud jste team-lead a zvažujete Inverse Conway Maneuver bez výslovného zadání od CTO, raději se nejdřív zeptejte. Detail komunikace s managementem je v sekci 05.09.

Praktický checklist před spuštěním Inverse Conway Maneuver

Než zahájíte re-org, projděte následující seznam. Pokud na kterýkoli bod odpovíte „ne“, Inverse Conway je předčasný a v 90 % případů selže:

1. Existuje kanonická Context Map? Bez ní není definovaná cílová architektura. Krok 1 selhal a kroky 2–4 nemají kam směřovat. Pokud nemáte Context Map, začněte tam (kapitola o Context Mappingu).
2. Má reorganizace výslovnou podporu CTO / VP Engineering? Reorganizace je politický akt. Bez podpory shora není odpor odolatelný – lidé budou hledat výjimky a starou strukturu obnoví neoficiálně.
3. Máte 6 měsíců času? Re-org pod 6 měsíců typicky nefunguje. Lidé potřebují čas se přesunout, naučit se nové domény, vybudovat nové vztahy.
4. Existuje plán pro Platform team? Bez self-service platformy se stream-aligned týmy zaseknou na infrastruktuře. Platform team musí mít alespoň minimum-viable IDP připravený před re-orgem (1-click new-BC bootstrap, CI šablona, observability default).
5. Změřili jste DORA metriky před re-orgem? Bez baseline neumíte obhájit úspěch ani identifikovat regresi. Jednoduché měření: lead time z PR-merge do produkce, deployment frequency, change failure rate (% deploy s rollbackem), MTTR (medián času na vyřešení P1 incidentu).
6. Je organizace v Westrum generative kultuře? V pathological / bureaucratic re-org formálně proběhne, ale operativní vztahy se vrátí (sekce 05.09).
7. Je obsazená pozice „topology owner“? Někdo musí re-org vést na denní bázi – typicky staff engineer + manažer. Bez vlastníka se re-org rozplyne do běžných sprint priorit.

Pokud máte všech 7 bodů „ano“, máte vyšší šanci než průměr. Zbývá jen práce.

05.06 Cognitive Load – limit pro velikost týmu/BC

Pojem kognitivní zátěž (cognitive load) převzali Skelton a Pais z teorie učení Johna Swellera (1988). Sweller rozlišuje 3 typy zátěže, které se vážou i na softwarové týmy:

• Intrinsic load (přirozená) – komplexita samotné domény. „Bankovní risk engine“ má vyšší intrinsic load než „katalog produktů“. Toto se nedá snížit, jen rozdělit mezi víc týmů.
• Extraneous load (zbytečná) – zátěž z prostředí, ne z domény: nestabilní CI, špatná dokumentace platformy, 5 různých deploy procesů, chaos v Slack kanálech. Toto je úkol Platform teamu odstranit.
• Germane load (rozvojová) – energie, kterou tým vkládá do učení a zlepšování. Toto má být pozitivní – pokud má tým přetížený intrinsic + extraneous, germane mizí (tým přestane investovat do zlepšení).

Cíl: maximalizovat intrinsic + germane, minimalizovat extraneous. Tým, který tráví 80 % energie zápasem s CI a deploy procesem, nemá kapacitu zlepšovat doménový model.

Pravidlo cognitive load pro počet BC na tým

Skelton a Pais doporučují praktickou heuristiku:

Jak změřit cognitive load (jednoduchá rubrika)

Skelton a Pais doporučují jednou za kvartál spustit s týmem 30-minutový workshop, kde každý člen ohodnotí na škále 1–5 následující:

1. Doménová komplexita (intrinsic) – „Rozumím kompletně doméně, kterou náš tým vlastní?“
2. Technická komplexita (intrinsic) – „Rozumím všem technologiím, které používáme?“
3. Stabilita platformy (extraneous, inverze) – „Můžu se spolehnout na CI/CD, observability, deploy?“
4. Kvalita dokumentace (extraneous, inverze) – „Najdu potřebné info do 5 minut?“
5. Prostor na učení (germane) – „Mám každý sprint 1–2 hodiny na zlepšení/learning?“

Body 1+2 vysoké = tým má pod kontrolou intrinsic. Body 3+4 vysoké = Platform team funguje a extraneous load je nízký. Bod 5 vysoký = tým má kapacitu na germane.

Pokud je průměr bodu 5 pod 3, tým je v krizovém režimu – žádné nové BC, žádné nové technologie. Nejdřív stabilizovat extraneous load.

Zde je rubrika ve formátu, který stačí vlepit do docs/cognitive-load.md v repu týmu. Vejde se na 1 stránku A4, vyplní se za 30 minut na konci sprintu a je dobrým vstupem pro retro:

# Cognitive Load Rubric – Q?/YYYY

Tým: <název týmu>
Bounded Contexts ve vlastnictví: <seznam BC>
Velikost týmu: <N> lidí
Datum měření: YYYY-MM-DD

## 1. Doménová komplexita (intrinsic)
Otázka: „Rozumím kompletně doméně, kterou náš tým vlastní?“
Skóre 1–5: __
Komentář: ____________________________________________

## 2. Technická komplexita (intrinsic)
Otázka: „Rozumím všem technologiím, které používáme (jazyk, framework, DB, broker)?“
Skóre 1–5: __
Komentář: ____________________________________________

## 3. Stabilita platformy (extraneous, inverze)
Otázka: „Můžu se spolehnout na CI/CD, observability, deploy bez ad hoc oprav?“
Skóre 1–5: __ (5 = stabilní, 1 = každý deploy je dobrodružství)
Komentář: ____________________________________________

## 4. Kvalita dokumentace (extraneous, inverze)
Otázka: „Najdu v interní dokumentaci potřebné info do 5 minut?“
Skóre 1–5: __
Komentář: ____________________________________________

## 5. Prostor na učení (germane)
Otázka: „Mám každý sprint alespoň 2 hodiny na zlepšení / learning / refactoring?“
Skóre 1–5: __
Komentář: ____________________________________________

## Vyhodnocení (vyplní team-lead po sběru od všech členů týmu)

Průměr 1+2 (intrinsic kapacita): __
Průměr 3+4 (extraneous tlak):    __
Bod 5 (germane prostor):         __

## Akce na další kvartál

- [ ] Pokud bod 5 < 3 → zastavit přírůstek BC.
- [ ] Pokud body 3+4 < 3 → eskalovat na Platform team (extraneous load).
- [ ] Pokud body 1+2 < 3 → zvážit split BC nebo přidání člena týmu.
- [ ] Pokud > 4 BC ve vlastnictví → naplánovat split do 2 kvartálů.

Rubrika je záměrně subjektivní – měří vnímání členů týmu, ne metrické fakty. Důvod: cognitive load je psychologická kategorie, žádná metrika z Grafany ji nezachytí. Skelton a Pais (2019, kap. 6) výslovně varují před snahou cognitive load „objektivizovat“ přes počet řádků kódu, count of services, nebo ticket throughput. Tyto proxy metriky nemají korelaci s tím, jak se tým reálně cítí.

05.07 Praktické scénáře (5 / 20 / 200+ lidí)

Team Topologies není doktrína „udělejte všech 4 typy týmů a 3 módy hned“. Je to jazyk, kterým se popisuje aktuální stav a cíl. Konkrétní podoba závisí na velikosti organizace.

Scénář A – Startup, 5 lidí, 1 produkt

Doporučení: 1 stream-aligned tým, 2–3 malé BC v jednom monolitu (modulární monolit). Žádný Platform team, žádný Enabling team.

• Architektura: jeden Symfony monolit; BC jsou složky/moduly s explicitními rozhraními (kapitola o architektonických stylech).
• Generic subdomény: SaaS – Auth0 nebo Clerk pro identity, Stripe pro fakturaci, SendGrid pro e-mail. Žádný vlastní implementace.
• Hosting: Heroku, Vercel, Railway, Fly.io – managed services nahrazují Platform team.
• Čeho se vyvarovat: nepouštět se do Kubernetes, vlastní observability stack, mikroservisy. Předčasné.

Chyba startupů: kopírovat enterprise architekturu „aby to bylo připraveno na budoucnost“. Cognitive load 5-členného týmu nemá kapacitu na 6 mikroservisů. Modulární monolit je správná volba.

Scénář B – Scale-up, 20 lidí, 1 produkt s rostoucí komplexitou

Doporučení: 2–3 stream-aligned týmy podle BC + 1 mini-Platform team (3–5 lidí) na CI/CD a observability. Žádný permanentní Enabling team.

• Stream-aligned týmy: rozdělené podle hlavních value streamů. Např. Catalog tým (5 lidí), Ordering tým (6 lidí), Identity+Billing tým (4 lidi, sdílí 2 supporting BC).
• Platform team: 4 lidi, vlastní CI pipeline šablonu, K8s cluster, Grafana/Sentry, šablonu pro nový BC. Self-service.
• Enabling team: ne na trvalo. Pokud potřebujete zavést CQRS, najměte si externího konzultanta na 3 měsíce.
• Interakční módy: Stream-aligned týmy mezi sebou X-as-a-Service. Platform team se všemi v X-as-a-Service. Příležitostná Collaboration při bootstrapu nového BC.

Tato fáze je nejrizikovější – organizace už není malá, ale ještě nemá kapacitu na plný rozsah Team Topologies. Klasická chyba: vznikne Center of Excellence („architektonický výbor“), který se stane bottleneckem.

Scénář C – Enterprise, 200+ lidí, 10+ BC

Doporučení: plná Team Topologies struktura.

• 10–15 stream-aligned týmů, každý vlastní 1 BC (případně 2 související supporting BC).
• 1–2 Platform teamy – typicky 1 hlavní (IDP, K8s, observability) + někdy specializovaný (data platform, ML platform).
• 1–3 Enabling teamy – rotující, time-boxed, podle aktuálních potřeb (např. „security enabling team“ na 6 měsíců, „event sourcing enabling team“ na 3 měsíce).
• 1–2 Complicated-subsystem teamy – jen pro objektivně specializované domény (např. risk engine v bance, video transcoder v médiích, ML scoring v ad-techu).
• Topology design: Skelton a Pais doporučují, aby v této velikosti existoval malý topology team (1–2 lidi, není to Center of Excellence) – sleduje cognitive load týmů a navrhuje reorganizace. Často je to staff engineer + manažer.

Důležité: i v 200-členné firmě by mělo být aspoň 75 % lidí ve stream-aligned týmech. Pokud máte 200 lidí a 100 z nich je v Platform/Enabling/CoE/architekti, máte problém – stream-aligned týmy nesou doménovou hodnotu, ostatní jsou multiplikátory. Multiplikátorů nemá být víc než multiplicandů.

05.08 Anti-vzory

Než se dostaneme k tomu, jak to udělat, je užitečné vědět, jak to nedělat. Následujících pět anti-vzorů je ze zkušenosti autorů Team Topologies nejčastějších a nejdražších. Detailní katalog DDD anti-vzorů je v samostatné kapitole o anti-vzorech.

1. „Sdílíme jeden monorepo bez hranic modulů“

Více týmů commituje do jednoho repozitáře bez jasných hranic mezi moduly. Důsledek: každá netriviální změna jednoho týmu vyžaduje code review od ostatních („jen abychom se ujistili, že to nic nerozbije“). Druhý tým má fakticky veto na změny prvního.

Řešení: buď jasné hranice modulů v monorepu (Nx, Bazel, Turborepo pro JS; doctrine bundles pro Symfony) s explicitními ownerships v CODEOWNERS, nebo separátní repa per BC. Nikdy ne princip „všichni do jednoho repa, nějak se domluvíme“.

2. „Frontend / Backend / Mobile týmy“

Klasický anti-vzor přímo z Conway's Law – týmy rozdělené po vrstvách. Každý feature vyžaduje koordinaci 3 týmů, 3 sprintů, 3 retrospektiv. Lead time přes 6 týdnů na úpravu, která si vyžádá zhruba 3 dny práce.

Řešení: Inverse Conway Maneuver. Rozpustit horizontální týmy a poskládat vertikální stream-aligned týmy, kde má každý tým všechny potřebné role (frontend dev + backend dev + mobile dev + QA + designer). Pokud je mobile aplikace zásadní část produktu, ne extra-feature, mobile vývojáři patří do stream-aligned týmů, ne do separátního „mobile týmu“.

Výjimka: pokud máte jen jednoho mobilního vývojáře na celou organizaci, dočasná „mobile guild“ má smysl – ne jako tým s vlastním backlog, ale jako komunita pro sdílení znalostí.

3. „Center of Excellence“ místo Enabling teamu

Permanentní útvar „architektů“ / „expertů“ / „vedoucího týmu“, který drží schvalovací pravomoc nad ostatními. Klasická corporate inkarnace: ARB (Architecture Review Board), který musí každou novou službu schválit.

Co je špatně: CoE typicky drží kontrolní bod, ne expertní podporu. Schvalování ze své podstaty zpomaluje, vytváří frontu a zbavuje stream-aligned týmy odpovědnosti („to nám neschválili, nemůžeme za to“).

Řešení: CoE → Enabling team. Time-boxed, mentoring místo schvalování, rozpuštění po předání. Pokud je „schvalování“ nutné, dělá ho stream-aligned tým sám podle dokumentovaných standardů, ne externí výbor.

4. „Platform team jako gatekeeper / ticketová fronta“

Platform team, který funguje jako infrastructure ticket support: stream-aligned tým potřebuje nový Postgres, vytvoří JIRA ticket, čeká 5 dnů. Potřebuje upravit CI pipeline, vytvoří ticket, čeká týden. Reálně se z Platform teamu stal úzký bottleneck pro celou organizaci.

Řešení: Platform team má povinnost dodávat self-service rozhraní (CLI, portál, IaC moduly). Pokud stream-aligned tým musí zadávat tikety, je to chyba designu platformy, ne chyba zadávajícího týmu.

Hlavní metrika: time-to-first-deploy pro nový BC. V zdravé organizaci pod 1 den. V nezdravé organizaci „ozkoušíme to za měsíc, jakmile platform team má kapacitu“.

5. „Sdílený Bounded Context mezi 2 týmy“

Dva stream-aligned týmy oba commitují do stejného Bounded Contextu, protože „to dává smysl“. Conway's Law okamžitě reaguje – vznikne neformální sub-hranice (čára „naše/vaše“ v kódu), ale bez formální Context Map. Tato čára se petrifikuje a po 6 měsících je z toho de facto Big Ball of Mud s dvěma vlastníky.

Řešení: rozdělit BC na 2 menší BC se Shared Kernel (drahý, viz Context Mapping) nebo Customer/Supplier vztahem. Případně sloučit 2 týmy do 1 většího – pokud doména opravdu nejde rozdělit.

05.09 Komunikace s managementem – jak prodat re-org

Inverse Conway Maneuver je hluboká organizační změna. Týmy bude třeba rozdělit, manažery přealokovat, lidé možná ztratí senioritu nebo „svůj koutek“. Bez pochopení a podpory managementu (CTO / VP Engineering / People Ops) Inverse Conway selže – protože re-org bez podpory shora se v praxi neudělá vůbec.

Podstatné je mluvit jazykem, kterému management rozumí – ne jazykem DDD. Manažeři neumí ocenit „elegantnější doménový model“ nebo „čistější Bounded Contexts“. Umí ocenit metriky.

Argumenty, které fungují (DORA metriky)

Nicole Forsgren, Jez Humble a Gene Kim v knize Accelerate (2018) [4] zveřejnili 4 metriky (DORA), které měří efektivitu doručování softwaru a které silně korelují s obchodními výsledky (zisk, růst, customer satisfaction):

• Lead time for changes – čas od commitu do produkce. Stream-aligned týmy: hodiny. Horizontální týmy: dny–týdny.
• Deployment frequency – kolikrát za den/týden deploy. Stream-aligned: víckrát denně. Horizontální: 1× za sprint.
• Change failure rate – % deploymentů, které způsobí incident. Stream-aligned: pod 15 %. Horizontální: 30–60 %.
• Mean time to restore (MTTR) – čas zotavení z incidentu. Stream-aligned: hodina. Horizontální: dny.

Před re-orgem změřte 4 DORA metriky. Po re-orgu změřte znovu po 6 měsících. Pokud Inverse Conway funguje, lead time se zkrátí o 30–80 %, change failure rate se sníží o 30–50 %. Tato čísla CTO chápe.

Argumenty, které nefungují

• „Eric Evans by to chtěl“ – manažer není v DDD komunitě.
• „Je to elegantnější“ – manažer neměří eleganci.
• „Bounded Contexts jsou kanonické“ – manažer neměří kanoničnost.
• „Zlepší se to“ – bez metriky je „zlepší“ prázdné slovo.
• „Skelton a Pais to říkají“ – autorita argumentem nestačí.

Westrumova kultura organizace

Sociolog Ron Westrum v roce 2004 publikoval typologii organizačních kultur [5], kterou později použil Forsgren v Accelerate jako hlavní prediktor úspěchu DevOps transformací. Westrum rozlišuje 3 typy:

Team Topologies funguje jen v generative kultuře. V pathological kultuře (manažer trestá za chyby, hierarchie je vše) stream-aligned týmy nedostanou autonomii – manažer chce mít kontrolní bod, takže Platform team se stane gatekeeper. V bureaucratic kultuře (přesné role, formální procesy) reorganizace projde, ale provozní vztahy zůstanou – Conway's Law přijde zpět přes formální schvalování.

Pokud poznáte, že vaše organizace je pathological nebo bureaucratic, Inverse Conway Maneuver není první krok. První krok je změna kultury (nebo i změna pracoviště). To je smutná, ale realistická diagnóza.

05.10 Shrnutí

Conway's Law z roku 1968 říká: architektura kopíruje organizační strukturu. Pro DDD to znamená jednu věc – Bounded Context bez vlastnícího týmu je fikce. Pokud máte 7 BC v Context Mapu a 3 týmy v org chartu, vaše BC neexistují, jen jsou napsané v dokumentaci.

Team Topologies (Skelton & Pais, 2019) je rámec pro vědomý návrh týmů, který doplňuje DDD tam, kde Vernon a Evans mlčí. Hlavní poznatky:

• 4 typy týmů: Stream-aligned (vlastní BC end-to-end, výchozí), Platform (self-service IDP), Enabling (time-boxed mentoring), Complicated-subsystem (objektivně specializovaná doména).
• 3 interakční módy: Collaboration (drahá, časově omezená), X-as-a-Service (výchozí vyspělý vztah), Facilitating (mentoring time-boxed).
• Vernonovo pravidlo: 1 BC = 1 tým. 1 tým může vlastnit 1–3 BC, ale BC sdílený mezi týmy = porucha.
• Subdomény → typy týmů: Core → stream-aligned (nejlepší tým) / complicated-subsystem; Supporting → stream-aligned (sdílí tým s jiným supporting BC); Generic → SaaS, Platform team integruje.
• Inverse Conway Maneuver: nejdřív definovat cílovou architekturu, pak postavit týmy tak, aby ji přirozeně vyprodukovaly. Bez podpory CTO neuspěje.
• Cognitive load: ≤ 2 BC na 5–9 lidí. 4+ BC na tým = signál pro split. Měřte kvartálně.
• Proporce: 75 % stream-aligned, 15 % platform, 10 % enabling + complicated-subsystem.
• Komunikace s managementem: DORA metriky, ne DDD filozofie. Westrumova generative kultura je předpoklad, ne výstup.

Pokud z této kapitoly odejdete s jednou větou, ať je to tato: Bounded Context není soubor v repu – je to závazek konkrétního týmu vyvíjet, deployovat a opravovat v noci konkrétní část domény. Bez tohoto závazku není BC.

Pro hlubší studium doporučujeme Skelton & Pais – Team Topologies [3], Vernon – Implementing Domain-Driven Design, kap. 2 a 3 [2], a Forsgren et al. – Accelerate [4] pro DORA metriky a Westrumovu typologii. Originální Conway 1968 esej je krátká (4 strany) a stojí za přečtení [1].

05.11 Další četba a citované zdroje

1. Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(4), 28–31. melconway.com
2. Vernon, V. (2013). Implementing Domain-Driven Design. Addison-Wesley. Kap. 2 (Domains, Subdomains, Bounded Contexts) a kap. 3 (Context Maps). amazon.com
3. Skelton, M. & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press. teamtopologies.com
4. Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. itrevolution.com
5. Westrum, R. (2004). A typology of organisational cultures. Quality and Safety in Health Care, 13(suppl_2), ii22–ii27. qualitysafety.bmj.com
6. Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.
7. Související kapitoly na tomto webu: subdomény, context mapping, architektonické styly, anti-vzory.