DÍL 02a KAPITOLA 02 · SEKCE 02.01–02.04

Core Domain a subdomény: kam investovat

Core, Supporting a Generic subdomény: kde se vyplatí plné DDD, kde stačí CRUD a co koupit. Pětibodový test Core Domain a anti-vzor „všechno je Core“.

Přehrávač YouTube se načte až po kliknutí · otevřít na YouTube (nové okno) ↗

Přepis dílu komentář tak, jak zazní ve videu

Vlastní autentizace za šest člověkoroků

Ilustrativní scénář. Tech lead navrhne, že si tým napíše vlastní autentizaci, a odhadne ji na šest sprintů. Za osmnáct měsíců je z toho zhruba šest člověkoroků.

Migrace na hotové řešení nakonec stejně proběhne, jen o rok a půl později. Přitom stačilo položit si na té schůzce dvě otázky.

Proč subdomény předcházejí všemu

Ne každá část aplikace si zaslouží stejnou hloubku modelování. Kdo pečlivě modeluje úplně všechno, vyčerpá rozpočet dřív, než se dostane k tomu, co zákazníka skutečně zajímá.

Eric Evans pro tenhle filtr v roce 2003 zavedl dva pojmy, Core Domain a Generic Subdomain. Třetí kategorii pojmenoval jako samostatný vzor až Vaughn Vernon v roce 2013. Je to Supporting Subdomain.

Obchodní myšlenka je přitom starší. Geoffrey Moore dělí činnosti firmy na ty, které ji odlišují od konkurence, a na zbytek. Ten radí minimalizovat, automatizovat nebo outsourcovat.

Jen bacha, subdoména je něco jiného než Bounded Context. Subdoména ohraničuje kus obchodu. Bounded Context je implementační hranice, uvnitř které platí jeden model.

Vztah mezi nimi přitom nemusí být jedna ku jedné. Subdoména Pricing se může rozdělit do dvou kontextů. Catalog počítá orientační cenu, Checkout závaznou. Opačně funguje kontext Backoffice, který sdruží kousky reportingu, fakturace i správy uživatelů.

Rozlišit je pomůže krátký test. Existoval ten pojem ve firmě dřív než IT systém? Pak je to subdoména. Vznikl kvůli oddělení modelů v softwaru? Pak je to Bounded Context.

Chyba v subdoménách stojí násobně víc než chyba v agregátu. Podle knihy se špatně navržený agregát refaktoruje za dva sprinty. Špatně určená Core Domain znamená rok vývoje v nesprávné oblasti. Proto strategický design přichází před taktickým a DDD-Lite z prvního dílu dělá přesný opak.

Tři kategorie subdomén

Core Domain je konkurenční výhoda, tedy to, kvůli čemu zákazníci platí právě vám. Kontrolní věta zní: když z toho zítra ustoupíme, ztratíme zákazníky.

Sem patří plný taktický design, seniorní tým, nejvíc testů a nejčastější rozhovory s doménovými experty.

Supporting subdoména je nutná pro provoz, ale neodlišuje vás. Potřebujete ji, jen vás kvůli ní nikdo nenajme. Typicky evidence skladu, fakturace nebo reporting pro vedení.

Často v ní stačí CRUD nad Doctrine entitami a mediorní tým. Cílem je spolehlivý provoz s minimálními náklady na údržbu. Nejhezčí model tu nikoho nezajímá.

Generic subdoména je komodita. Patří sem autentizace, transakční e-maily, platební brána nebo generování PDF faktur. Výchozí volbou je koupit a napojit.

Evans je v tom opatrnější. Vlastní implementaci uvádí jako jednu ze čtyř přípustných možností. Obhájit se dá tam, kde by integrace stála víc než samotný vývoj.

Khononov k tomu přidává další dvě osy, složitost a volatilitu. Core i Generic jsou složité, jenže Generic je složitý problém, který už někdo vyřešil a který se nemění.

A složitost v Supporting subdoméně je signál. Buď se v ní schovává nerozpoznaná Core Domain, nebo je nahodilá a nikdo ji tam nechtěl.

Jak rozpoznat Core Domain

Rozpoznat Core Domain je nejtěžší krok, protože každá oblast má svého obhájce. Kniha k tomu nabízí rychlý pětibodový test. Sestavil ho autor knihy, v literatuře ho v téhle podobě nenajdete.

Přijdeme outsourcingem o hlavní produkt? Chybí pro tu oblast tržní standard? Děláme to jinak než konkurence?

Mluví o tom vedení každý týden? A měníme v té oblasti pravidla často? Tři a víc odpovědí ano znamená kandidáta na Core.

Zkusme to na autentizaci. Když ji outsourcujete, o produkt nepřijdete. Standard existuje, OAuth a OpenID Connect. Konkurence ji má stejnou, vedení o ní nemluví a pravidla se nemění. Nula odpovědí ano, takže Generic.

Jemnější pohled dávají Core Domain Charts. Na svislé ose je složitost, na vodorovné obchodní diferenciace. Subdomény se do grafu zakreslují jako body.

Hlavní přínos vidí autoři grafu jinde. Složitost odhadují inženýři, diferenciaci byznys a tady musí obě skupiny postavit své odhady vedle sebe. Subdoména, která padne mezi oblasti, je pak téma k rozhovoru.

A když test vyjde na pět Core domén? Pak je to varovný signál, protože Core bývá vzácné. Záleží na tom, čím se odlišujete právě vy. Logistika je v Amazonu Core, jenže v e-shopu, který posílá balíky přes DPD, je Generic.

Anti-vzor: všechno je Core

Na strategické úrovni čeká jedna velká past. Kniha jí říká všechno je Core. Zeptejte se kteréhokoli vývojáře, jestli je jeho oblast strategická, a odpoví, že ano.

Vedení to pak nemá jak rozsoudit. Rozpočet se rozteče rovnoměrně a skutečná Core Domain dostane stejně jako fakturace.

Technicky z toho vznikne model bez priorit. Každá entita je prvotřídní, každý případ užití má vlastní agregát a refaktoring jednoho zákoutí se dotkne dvaceti dalších.

A zpátky k té autentizaci. Na schůzce nepadly dvě otázky. Existuje tržní standard? Ano. Odlišuje nás to od konkurence? Ne.

Obrana je přímočará: rozpočet ve třech škatulkách. Kniha pro průměrnou B2B SaaS firmu počítá s dvaceti až třiceti procenty kapacity na Core. Na Supporting jde padesát až šedesát procent a na Generic deset až dvacet.

Je to pravidlo palce, ne naměřená data. Ale když do Core spadne osmdesát procent, klasifikace selhala.

Otázka a shrnutí

Krátká otázka na rozmyšlenou. Tým si chce napsat vlastní rozesílání transakčních e-mailů. Do které kategorie patří?

Generic. Transport e-mailů se konfiguruje, nepíše. Stačí ho koupit a napojit přes tenkou vrstvu. Jinak by to bylo jen tehdy, kdybyste rozesílání e-mailů sami prodávali.

Takže v kostce. Subdomény rozhodují, kam půjde úsilí, ještě než vznikne první agregát.

Core se staví, Supporting zjednodušuje a Generic kupuje. A když je všechno Core, pomůže test a rozpočet ve třech škatulkách.

Příští díl zůstává u subdomén, tentokrát v kódu. Ukáže, jak se klasifikace propíše do projektu v Symfony, kdo má který kód psát a proč časem stárne. Celou kapitolu najdete v knize na ddd-v-symfony.katuscak.cz.

← Všechny díly videokurzu