Business většinou pokrývá více oblastí. Nezáleží ani tak na tom, jestli se jedná o velkou nadnárodní společnost, například Amazon, nebo o malý rodinný e-shop. Obě firmy musí řešit produktový katalog, evidenci skladu, košík, platby, fakturaci atp. Malý e-shop bude samozřejmě používat mnohem jednodušší software a bude se moci pochlubit řádově nižší mírou automatizace. Ale zkrátka nejde provozovat e-shop, ve kterém nejsou žádné produkty, který nemá košík nebo který nevystavuje faktury za zakoupené zboží.
V terminologii DDD těmto oblastem říkáme business domény nebo subdomény. Pro účely tohoto článku ve zmíněných pojmech není rozdíl a v následujícím textu oba znamenají totéž.
Mohlo by se zdát, že nejsnadnější, a tedy i nejlevnější způsob implementace e-shopu je tvorba jednoho doménového modelu, který by zahrnoval celý business. Ale je to opravdu dobrý nápad?
Ukazuje se, že složitost takového všezahrnujícího modelu rychle roste. S přibývajícími entitami dochází ke kolizím v názvech, což vede vývojáře k vymýšlení specifičtějších pojmů, které používají ve zdrojovém kódu, ale nikoli už v mluvené komunikaci. Přibývají vazby mezi entitami a celý model je stále více provázaný. Míchají se v něm různé koncepty, které nejsou explicitně vyjádřeny a místo nichž se volí spíše obecné konstrukce. To vše vede k tomu, že se model postupně stává stále náročnějším na pochopení. Nakonec se dostane do stavu, kdy už není v silách vývojářů ho celý pochopit. Pro takový model používáme pojem Big Ball of Mud.
Lepší nápad je rozdělit business do subdomén a pro ně vytvořit samostatné doménové modely, které budou menší, budou mít užší zaměření, a tím pádem budou i snáze pochopitelné. Jak ale subdomény poznat? Jedním z vodítek může být, když doménový expert používá pro stejnou věc více různých pojmů. Například pokud mluví o člověku, který si objednal zboží, ale v jednu chvíli ho nazývá zákazníkem a ve druhou příjemcem. V takovém případě jsme pravděpodobně překročili hranici dvou subdomén.
Vodítkem může být i opačný případ. Když doménový expert používá stejný pojem pro různé věci. Například účtem jednou myslí bankovní účet a podruhé uživatelský účet. I to může znamenat, že přecházíme mezi dvěma subdoménami.
Význam pojmů vždy záleží na kontextu, v jakém jsou proneseny. Naším cílem je najít takové subdomény, ve kterých mají pojmy jednoznačný význam.
Podařilo se vám subdomény identifikovat? Výborně! Než se pustíte do modelování, je dobré si uvědomit, že ne všechny subdomény jsou pro business stejně důležité a že ne všechny si zaslouží investici do tvorby doménového modelu. Věnovat celému systému stejnou pozornost by nebylo finančně efektivní.
Subdomény dělíme do 3 kategorií podle toho, jak jsou důležité a jakou péči si tedy zaslouží:
Core doména
Jedná se o firemní know-how. O to, co firmu odlišuje od konkurence. Je to ta část, která má pro business největší hodnotu a kvůli které se vyplatí vyvíjet vlastní software místo koupě krabicového řešení. Proto je důležité této oblasti věnovat největší pozornost a nasadit na ni talentované vývojáře.
Supporting doména
Jedná se o subdomény, které sice nepřináší žádnou konkurenční výhodu, ale bez nichž by zároveň core domain nemohla fungovat. Na trhu většinou nelze koupit hotové řešení, proto se musí implementovat vlastní. Snažíme se o co nejjednodušší a nejlevnější implementaci. Tyto domény jsou vhodné pro juniorní vývojáře, kteří zde mohou zlepšovat své dovednosti.
Generic doména
Jedná se o subdomény, které nejsou ničím speciální, ale stále jsou potřeba, aby business fungoval. Patří sem věci jako odesílání mailů, generování faktur atp. Může být dokonce lepší koupit již hotové řešení než investovat do vlastního vývoje.
Vždy záleží na konkrétní firmě, co je právě pro ni core, supporting nebo generic doména. Platí taky, že co je pro jednu firmu generic doména, může být pro druhou core doména. Pro e-shop bude například online chat patřit do kategorie generic. Pro společnosti, které chat vyvíjí, se bude jednat o core doménu.
Firma se také může časem transformovat. Co bylo dříve generic doménou, se později může stát core doménou. Naopak tím, co bylo zprvu core doménou, se může firma úplně přestat zabývat, pokud se ukáže, že v tom není úspěšná.
Resumé tedy je, že některé části systému jsou pro business důležitější než jiné, a je potřeba je umět správně identifikovat.
Reference
Vaughn Vernon. Implementing Domain-Driven Design. Addison-Wesley, 2013. ISBN 0-321-83457-7.
Sccott Millett with Nick Tune. Patterns, Principles, and Practices of Domain-Driven Design. John Wiley & Sons, 2015. ISBN 978-1-118-71470-6
Sdílet článek