Ten istý softvérový projekt vnímajú rôzni ľudia rôzne. Projektový manažér sa na neho bude pozerať ako na kombináciu projektových parametrov – rozpočet, termíny a rozsah prác. Biznis analytik ho bude chápať ako nositeľa biznis hodnoty pre používateľov. Databázový správca sa na neho bude pozerať skrz údaje – kde a aké údaje sú uložené, v akej kvalite, atď. A programátorovi začne projekt dávať zmysel, keď pochopí technologický stack. Takto by som mohol pokračovať ďalej, ale fakt je, že softvérový projekt a softvér ako taký existuje vo viacerých doménach naraz. Analýza všetkých a ich vzájomné interakcie sú kritické pre pochopenie, prečo jeden projekt môže uspieť a iný nie. Ja sa teraz pozriem na dve z nich – biznis a technológiu.

Možno ste to zažili. Sedíte na plánovacom stretnutí, kde sa preberajú nové funkcionality. Biznis analytik hovorí o tom, že potrebujeme do systému doplniť funkcionalitu na import údajov z externého systému. Softvérový architekt sa na chvíľu zamyslí a povie, že by sme to mohli nahrať na server, a potom na to použiť knižnicu XY. Obidvaja hovoria o tom istom. O niečom novom, čo sa bude v systéme implementovať, ale každý z perspektívy svojej domény, a pritom sa navzájom snažia pochopiť doménu toho druhého.

Toto preskakovanie z jednej domény do druhej sa na softvérovom projekte deje neustále. Ak ste niekedy zažili nedorozumenie medzi analytikmi a vývojármi, bolo to preto, lebo jedna alebo druhá strana nevedela pochopiť pohľad tej druhej. Výsledok môže byť, že sa naprogramuje niečo iné ako malo byť. Jedným z dôvodov, prečo je v agilných metódach ceremónia dema je ten, aby si obe strany navzájom potvrdili, že si porozumeli.

Pochopenie ako tieto dve domény na projekte koexistujú je kľúčové. Hlavným pilierom technologickej domény je takzvaný technologický stack – zoznam technológií, platforiem a knižníc s ich vzájomnými závislosťami (napríklad klientska aplikácia je závislá od bežiaceho servera). Biznisová doména je často reprezentovaná zoznamom biznis funkcionalít, ktoré môžu byť tiež usporiadané do hierarchie, ale môžu byť aj nezávislé. Technológia tak môže predstavovať pomyselnú vertikálnu os softvéru, zatiaľ čo biznisové funkcie jeho horizontálnu os. A teraz príde tá dôležitá časť: väčšina softvéru v priebehu času rastie omnoho viac v biznisovej doméne (do šírky) ako v tej technologickej (do výšky). To znamená, že aplikácia bude v priebehu času naberať viac biznis funkcionality ako nových technológií.

Tento jednoduchý fakt má na projekt dopad. Napríklad na štruktúru artefaktov (dokumenty, artefakty a súbory). Ak ich usporiadate podľa biznisovej domény, tak je tento systém lepšie škálovateľný (t.j. vie sa vysporiadať s ďalším rastom) ako keď to urobíte na základe technologickej domény. Pekným príkladom sú triedy v zdrojovom kóde usporiadané v určitej adresárovej štruktúre. Túto adresárovú štruktúru môžete zvoliť tak, že adresáre budú predstavovať kategórie tried (služba, trieda pre mapovanie, dátová trieda) a v nich budú triedy týkajúce sa rôznej funkcionality. Toto je usporiadanie podľa technologickej domény. Alebo budú adresáre reprezentovať biznis funkcionality a zahŕňať v sebe rôzne typy triedy. Toto je usporiadanie podľa biznisovej domény.

Väčšina platforiem postupne prešla na usporiadanie podľa biznisovej domény, lebo ak vám aplikácia rastie v množstve novej funkcionality, tak toto riešenie sa dá dobre škálovať. Ak to máte usporiadané podľa technologickej domény, tak budete mať pravdepodobne po čase pár adresárov s veľkým množstvom súborov – teda to bude omnoho menej prehľadné. Toto usporiadanie podľa jednej alebo druhej domény môžete zvažovať aj pri testovacích prípadoch, konfiguráciach, dokumentácii a iných artefaktoch, ktoré na projekte vznikajú.

V svete softvérových projektov už nejaký čas prebieha snaha tieto domény od seba odseparovať a urobiť v tom tak trochu poriadok. Pekným pokusom ako od seba ako tak odseparovať biznisovú a technologickú doménu je The Clean Architecture. Doména je tam reprezentovaná jadrom – skupinou tried, ktoré obsahujú dáta aj logiku relevantnú pre biznis. Ďalšie – vonkajšie vrstvy – potom obsahujú viac-menej len technologickú doménu. Ďalším príkladom je Domain-Driven design, ktorý sa snaží navrhovať štruktúry tried v prvom rade z pohľadu biznisovej domény. Ani jedno z tých riešení nie je dokonalé, ale obe majú šancu priniesť lepšie usporiadanie a pochopenie pre projekt.

Na záver ešte jeden príbeh, prečo je pochopenie domén na projekte dôležité. Pár rokov dozadu som robil na projekte, kde sa niekoľko vývojových tímov podieľalo na vývoji jedného informačného systému. Vedenie firmy sa rozhodlo rozdeliť tento systém iba z biznisového hľadiska. Tímom teda pridelili implementovať funkcie v systéme bez ohľadu na to, kde tieto funkcie nachádzali. Výsledok bol, že jeden tím mal robiť zmeny v rôznych častiach systému – častokrát vo viacerých klientskych a serverových aplikáciách naraz. Príspevky od rôznych tímov sa mali často integrovať na úrovni tried v jednej aplikácii.

Problém je, že hranice v biznisovej doméne sú často niekde inde ako v tej technologickej. A vývojári systém chápu v prvom rade v technologickej doméne. Preto väčšina tomuto rozdeleniu nerozumela, pretože tam, kde v biznisovom svete bola jasná hranica, v kóde to tak nemusí byť. Ako ľudia, ktorí pochádzali z technologickej domény, si vytvorili mentálny model systému, ktorý bol rozdelený podľa úplne iných deliacich čiar. Pozerali na systém ako na sústavu aplikácií (klientskych, serverových) a nie ako na sadu biznis funkcionalít, ktoré idú niektoré skrz niekoľko aplikácií. Výsledok bol chaos. Chaos, ktorý skončil tým, že sa po niekoľkých mesiacoch prerozdelili úlohy medzi tímami tak, aby toto rozdelenie viac rešpektovalo prirodzené hranice technologickej domény – ktoré tvoria hlavne samostatné aplikácie a ich rozhrania. Týmto nechcem povedať, že rozdelenie vývoja podľa biznis funkcionalít nie je možné. Ide skôr o to, že to nemusí byť tak jednoduché. Dôležité je si uvedomiť, že rôzni ľudia na projekte pochádzajú z iných domén, a teda chápu projekt inak, a toto rešpektovať. O styčných a trecích plochách medzi rôznymi rolami na projekte (projektoví manažéri, testeri, DevOps ľudia) si môžeme povedať niekedy nabudúce.