Subdomény v Symfony: kód, sourcing, audit
Jak se Core, Supporting a Generic propíšou do Bounded Contextů, do struktury projektu v Symfony a do rozhodnutí build, nebo buy. A proč klasifikace stárne.
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
Tentýž Order, jiný kód
Tentýž Order najdete v knize dvakrát. Jednou jako plný agregát s továrnou place, podruhé jako Doctrine entitu, která umí jen potvrdit a zrušit.
A obojí je správně. Rozhoduje o tom, do jaké subdomény objednávky ve vašem byznysu patří.
Mapování subdomén na Bounded Contexty
Subdoména a Bounded Context se mapují třemi způsoby. Jedna ku jedné, jedna subdoména do více kontextů, nebo víc malých subdomén v jednom kontextu.
Vernon doporučuje cílit na jedna ku jedné. Khononov jde dál a před dělením souvislé funkcionality varuje. Stejná změna pak zasáhne oba kontexty a vynutí si jejich společné nasazení.
Kniha k tomu přidává vlastní doporučení: rozdělit subdoménu dává smysl hlavně z provozních důvodů. Příkladem je Pricing, kde se katalog a pokladna škálují i nasazují jiným tempem.
Generic subdoména vlastní kontext většinou nemá. Přebírá cizí, třeba Auth0 nebo Stripe, a náš model od něj odděluje tenká vrstva, Anti-Corruption Layer.
Reporting jde opačným směrem. Prodej, sklad i marketing jsou malé subdomény a sdílejí jeden kontext s read modely.
Subdomény v Symfony: struktura a kód
Výchozí dělení Symfony na Controller, Entity a Repository je technické. Kdo hledá, jak se počítá cena, musí projít všechny tři adresáře.
Kapitola ukazuje dvě lepší varianty. První dává pod src složky Core, Supporting a Generic. Ve složce Generic pak leží jen adaptéry.
Jenže klasifikace se časem mění, jak ukáže poslední část. Když se Pricing přesune z Core do Supporting, musíte přejmenovat namespace v celém projektu. Přesně takovou změnu tým odkládá.
Druhá varianta, kterou popisuje Matthias Noback, dává na první úroveň kontext a klasifikaci drží v dokumentaci. Kniha dál používá právě ji.
Kolik do subdomény investujete, je vidět na objemu kódu. Pricelist v Core je agregát s událostmi a s pojmenovanou výjimkou pro konfliktní cenové pravidlo.
Order v Supporting je obyčejná Doctrine entita, která umí potvrdit a zrušit. Holá DomainException je v ní přiznaná zkratka. Pojmenovaná výjimka má smysl tam, kde na ní někdo staví reakci, a u tří stavů objednávky to nikdo nedělá.
A autentizace v Generic? Při troše štěstí žádná vlastní třída, jen pár řádků konfigurace balíčku auth0 symfony.
Hranice mezi subdoménami nemusí hlídat jen code review. Deptrac nebo PHPArkitect shodí build v CI, jakmile Core začne záviset na Supporting. Zapnout je ale dává smysl až tehdy, když struktura vydrží první čtvrtletí.
Sourcing: stavět, nebo koupit
Z klasifikace plyne i to, kdo kód napíše. Core staví doma seniorní tým s doménovým expertem. Supporting jde postavit lehce, nebo koupit, pokud hotové řešení pokryje aspoň osmdesát procent potřeb. A Generic se kupuje, pronajímá nebo bere z open source.
Pro Generic subdoménu rozlišil Evans čtyři možnosti. Hotové řešení, publikovaný model, implementaci zadanou externí firmě a vlastní implementaci. V praxi se tyhle čtyři cesty často pletou dohromady.
Před podpisem smlouvy na SaaS se vyplatí položit si jednu otázku. Kupujeme Generic, nebo outsourcujeme Core?
V prvním případě je to čistý zisk: ušetříte čas a koupíte zkušenosti dodavatele. Ve druhém odevzdáváte třetí straně svou konkurenční výhodu.
Vendor lock-in je daň za Generic, tedy cena za to, že kód nepíšete sami. Vrstva mezi vaším modelem a službou je tenká, takže výměna jednoho SaaS za jiný zabere sprint nebo dva. Před lock-inem se chrání hlavně Core.
Klasifikace stárne: audit a Domain Vision Statement
Klasifikace přitom není jednorázová. Online platby byly v roce 2010 pro většinu firem Generic, jenže pro Stripe, který tehdy začínal, byly Core.
Opačně to potkalo synchronizaci souborů. Dropbox v ní měl v roce 2008 své Core. Po nástupu Google Drive, OneDrive a iCloud Drive se z ní stala komodita a firma musela Core posunout jinam.
Helpdesk si firmy dřív psaly samy jako Supporting subdoménu. Dnes ho pokryje Zendesk nebo Freshdesk, takže samotný ticketing se posunul do Generic. Supporting zůstávají jen vlastní pravidla podpory, třeba eskalace nebo vazba na objednávky.
Poslední posun je čerstvý a týká se zpracování textu. Třídění dokumentů, vytahování dat nebo shrnutí ještě před pár lety stavěl vlastní tým. Dnes stačí zavolat API jazykového modelu. Tvrdá čísla k tomu zatím žádný zdroj nenabízí, takže kniha to podává jako pozorování.
Proto kniha doporučuje audit subdomén každých dvanáct až osmnáct měsíců. Na půl dne se u něj sejde produktový management s architekty.
Výsledek se zapisuje do Domain Vision Statementu. Je to jedna stránka pro každou Core subdoménu: co to je, proč je to Core, kolik do toho investujeme a kdy klasifikaci přehodnotíme.
Když ho půl roku nikdo neaktualizoval, je něco špatně. Buď se v té oblasti nic neděje a možná už není Core, nebo dokument nikdo nečte.
Otázka a shrnutí
Krátká otázka na rozmyšlenou. Modelový e-shop zvažuje, že si výpočet cen koupí jako SaaS. Kupuje tím Generic, nebo outsourcuje Core?
Záleží na klasifikaci z minulého dílu. Když e-shop soutěží právě cenou, je Pricing jeho Core a nákup je strategický ústup. Pokud cenou nesoutěží, je Pricing nejspíš Supporting a hotové řešení dává smysl.
Takže v kostce. Subdoména je obchodní hranice, Bounded Context implementační a cílem je jedna ku jedné.
Z klasifikace plyne objem kódu, od agregátu přes entitu po pár řádků konfigurace, a taky to, co postavit a co koupit. A protože stárne, patří k ní pravidelný audit a jednostránkový Domain Vision Statement.
Příští díl je o Context Mappingu, tedy o tom, jak spolu kontexty mluví. Celou kapitolu o subdoménách najdete v knize na ddd-v-symfony.katuscak.cz.