Design založený na doméně nemusí být obtížný. Zde je návod, jak začít

Andrew Hamel-Law

Viděl jsem mnoho týmů, které přijímají návrh založený na doméně (DDD), a viděl jsem, že se věci hodně zhoršují. Problémy často začínají ve velmi raných fázích.

Tento blogový příspěvek zkoumá základy DDD a dává vám cestu, kterou byste měli následovat. Bude označovat věci o DDD, které stojí za to přemýšlet, a také věci, které můžete bezpečně ignorovat. Existuje několik praktických rad a několik návrhů ohledně významných milníků na vaší studijní cestě. Získáte také rámec, na kterém budete stavět, když postupujete směrem k zvládnutí DDD, což je jeden z mála ověřených způsobů „řešení složitosti v jádru softwaru“.

Co je to „doménový design“?

Když řeknu „doménový design“, mluvím o procesu designu, který zavedl Eric Evans ve své knize z roku 2003 „Návrh na základě domény: řešení složitosti v srdci softwaru“. V něm definoval DDD jako „přístup k vývoji softwaru pro komplexní potřeby tím, že hluboce propojil implementaci s vyvíjejícím se modelem hlavních obchodních konceptů.“ Tato kniha, i když je neuvěřitelně čitelná (jedna z mých nejlepších tří knih pro vývojáře), může být také odkládací: na 560 stránkách je to vážná kniha.

Evansova kniha není jedinou knihou o DDD. „Implementace návrhu na základě domény“ od Vaughna Vernona je nejznámější - ale je to ještě delší. Můžete zkusit Vaughnův „Domain-Driven Design Distilled“, nebo možná, můj osobní favorit, „Anatomie Domain-Driven Design“ od Scott Millet a Sam Knight.

Přesto přes všechny tyto, lidé jsou stále opouští naprostý objem informací, a možná i počet možností, jak začít.

To mě dělá smutným, protože DDD je věc, která mě udržuje rozumně na projektech, udržuje kódové základny v linii a blízko k obchodnímu problému, a co je nejdůležitější, pomáhá týmům organizovat se a poskytovat.

Fáze 1: Začněte s obchodním problémem

Jak tedy začít? Zapomeňte na DDD.

Zcela.

Pamatujete si dny, které jste předtím slyšeli o designu založeném na doméně, a svou softwarovou doménu byste jen modelovali pomocí polí a linek?

Udělej to. Bavte se.

Jednoduše zkuste pochopit, jaký problém řešíte pomocí svého softwaru. Zapomeňte na „ohraničené kontexty“, „všudypřítomný jazyk“ a na všechny ostatní věci - dokonce zapomeňte na slovo „doména“.

Pokračuj. Pusť ... počkám tady na tebe.

Nyní zkusme pochopit náš obchodní problém.

Když to děláte, je hezké myslet pomocí stejných konceptů, jaké používáte pro psaní kódu - to znamená, že pokud budete psát kód v jazyce orientovaném na objekt, modelujte také OO způsobem. V ideálním případě budete mít tabuli, ale online nástroje jako draw.io jsou také skvělé. Nebojte se, nemusíte být mistrem UML. Podívejte se na věci Simona Browna pro snadné způsoby, jak toho dosáhnout, pokud to potřebujete. A starý, ale stále skvělý „UML destilovaný“ od Martina Fowlera je také velmi užitečný.

Fáze 2: Nepoužívejte jen kreslit, kódování je také modelování

Když to děláte, nezapomeňte se neustále pohybovat v kódu - udržujte smyčku mezi náčrtem na tabuli a odpovídajícím kódem velmi těsně. Pamatujte - lidé, kteří píší kód, by měli kreslit náčrtky, ale ti, kdo kreslí náčrty, musí psát kód. Proč? Protože váš kód je mnohem pevněji omezen a zkontrolován kompilátorem, verze modelů, které kreslíte perem, a jako takový píšete kód, stále děláte mnoho návrhových rozhodnutí.

Když jdete, dopřejte si na svém místě v kódové základně samostatné místo, abyste zachovali věci, které jsou model-y. Rád vytvářím balíček s názvem „model“, ale jiní jej nazývají „doména“. Buď je v pořádku. Udělejte radost sobě i svým kolegům. Přidejte si nějaké dílčí balíčky, pokud chcete věci udržovat uklizené.

Vezměte prosím na vědomí: Je přirozené, že se trochu frustruje, protože rámec a instalatérské věci - věci, které opravdu nejsou modelem - se začnou vplížit do tohoto „modelového“ balíčku. Nebojte se. Znečištění modelu se vždy stane - když jsem začal, byly to kousky Enterprise JavaBeans a v těchto dnech je stejně pravděpodobné, že se jedná o věci Spring Framework.

Chci vás požádat, abyste žili s tímto modelem znečištění trochu. To je v pořádku. Jen si zvykni na pocit, že tě to frustruje. Je to dobrý pocit poznat.

Fáze 3: Společný návrh s kolegy z vaší domény

Při modelování se ujistěte, že jste v úzkém kontaktu s odborníky, kteří skutečně rozumí skutečné verzi systému, který vytváříte. Možná budou konečnými uživateli. Zacházejte s nimi jako se svými spolu-vývojáři. Zná problém velmi podrobně, ale neví, jak kódovat (pravděpodobně). Jsi pravý opak.

Spojte se s nimi síly, abyste opravdu dostali hlavu kolem obtížných bitů a vytvářeli úžasná řešení. Udržujte věci pro své odborníky snadné pomocí výrazů, které používají k popisu svého světa v softwaru. Nejen substantiva, ale i slovesa; například nejenom „BankAccount“, ale také také „CreditAmount“ a „close“. Pozorně poslouchejte slova odborníka. Zeptejte se mnoha otázek, abyste získali jasnost a sdílené porozumění, ale nikdy na ně neukládejte svá slova. Pomozte řídit tento sdílený jazyk a model tím, že píšete testy jednotek v jazyce, se kterým jsou experti 100% spokojeni.

Můžete posunout věci dále tím, že si zařadíte své spolupracovníky jako odbornou čočku a identifikujete technické instalatérské / rámcové věci, které se vplížily do vašeho krásného čistého modelu. Jakmile zjistíte znečištění, můžete jej přesunout ze svého „modelového“ balíčku na jiné místo ve vaší kódové základně, jakmile to bude pohodlné.

Zkontrolujte, zda jste v tomto vyčištění byli úspěšní, a předejte kód jednomu nebo více odborným kolegům, nebo ještě lépe, udělejte to, když s nimi párujete. Pokud jim to dává smysl (s malým vysvětlením syntaxe jazyka, který používáte, ale nikoli slovní zásoba), jste na správné cestě.

Nejlepší tipy:

  1. Udržujte věci čitelné.
  2. Pokud se dostanete do bodu, kdy váš model a váš odborník nesouhlasí, mají pravdu a model je špatný. Vždy. Změňte svůj model. To je průlom!

Pokud po tom nikdy nenarazíte na žádné problémy, pak gratuluji! Děláte design založený na doméně! Udělte si odznak za zásluhy o DDD!

Fáze 4: Když váš model praskne

V poslední chvíli jsem trochu ležel. Někdy se model a váš odborník mohou neshodnout. Může to být proto, že váš model je nesprávný (pravděpodobně), ale také proto, že váš model řeší jeden problém a váš odborník domény popisuje jiný problém. Modely by měly řešit pouze jeden problém a možná jste se právě dostali do bodu, kdy váš současný model nedokáže vyřešit všechny problémy, které potřebujete k vyřešení současně.

To je 100% v pořádku. To jen znamená, že pravděpodobně neexistuje způsob, jak to udělat s jediným modelem.

Pokud se dostanete k tomuto bodu, proveďte rychlou kontrolu: Jsou přítomny všechny prvky vašeho modelu, protože jsou potřebné k vyřešení problému? Pokud ne, odstraňte je. Všechny modely jsou abstrakce skutečného světa a nemusí obsahovat vše, co dělá.

Pokud vyřeší váš druhý problém, rozdělte kód v balíčku „model“ na dva. Podle toho rozdělte svůj kód. Udělejte to s pomocí vašich odborníků. Pokud nedostanou důvod, proč se rozdělujete, vysvětlete jim, jak nepoužíváte londýnskou podzemní mapu k procházce ulicemi. K tomu používáte jiný druh mapy. Mapa trubek je velmi specifická mapa, která řeší velmi specifický problém. Možná budu muset vyřešit „procházku po londýnském problému“, ale dělám to jiným způsobem. Totéž platí i zde.

Top Tip: Pravděpodobně budete chtít za tím účelem vrátit na tabuli.

"Ale" slyšel jsem, jak pláčete, "některé kousky mého původního modelu jsou nyní potřeba na dvou místech!" (Grrr! Frustrující!)

To je naprosto v pořádku. Jednoduše pokračujte a duplikujte potřebné bity. Zaměřte oba své modely na štíhlé, střední a řešení problémů. Bojíte se, že nebudete SUCHÉ? Přečtěte si „DRY is about knowledge“ od Mathiasa Verraese a poté si blahopřejeme k vyrovnání jako vývojář. Podívejte se také na podcast Davea Thomase a Andy Hunt's Changelog (Episode 352), který také hovoří o tomto tématu.

Top Tip: Ujistěte se, že kopírujete pouze bity, které potřebujete (tj. Pole / atributy a metody / funkce).

Dobře, nyní máte dva modely, z nichž každý řeší jeden problém. Jak víte, kam jde kód?

Odpověď je opět „promluvte si se svými odborníky“. Pravděpodobně přemýšlejí o dvou pracovních místech, když vám vysvětlili věci.

Top Tip: Nechte je, aby přemýšleli o pracovních titulech a „kloboucích“, které by mohli nosit v různých časech svého pracovního dne.

Ujistěte se, že se váš model dělí podél těchto linií. Když vysvětlují věci, které se chystají dopředu, zeptejte se jich „který klobouk máte, když to děláte?“ Začnou to velmi rychle, a brzy budete létat znovu.

Gratulujeme! Nyní jste objevili své první dva modely. A co víc, objevili jste také potřebu ohraničených kontextů. Udělejte si další záslužný odznak DDD!

Nyní jste připraveni se ponořit do knihy DDD a začít svou sólo-DDD cestu. Rád si myslím, že byste mohli jít rovnou k Ericově Modré knize. Pokud se vám to stále zdá skličující, podívejte se na oddíly Hands-On Modellers, Ubiquitous Language, Repository and Bounded Contexts. Budete překvapeni, jak rychle tyto věci zvládnete.

Původně zveřejněno na adrese https://www.thoughtworks.com 26. února 2020.