pondělí 18. dubna 2011

Obrácený design

V prezentaci na téma Java v Cloudu jsem mluvil o problému, kterým si myslím trpí většina softwárových návrhů, které jsem v poslední době slyšel. Soukromě jsem ho pokřtil Obrácený design a souvisí s posedlostí se kterou se snažíme šroubovat Enterprise Java řešení a technologie na všechny typy problémů, které před námi stojí. Během prezentace jsem použil slovní pyrotechniku "...lituji každého slova na téma Spring, které jsem kdy pronesl na blogu", teď bych rád nabídl trochu obšírnější popis toho co je Obrácený design a jak do něj výše pronesená a zapsaná věta zapadá.

Mějme aplikaci jako je LinkedIn sloužící k prezentaci a poskytování profesních profilů jednotlivých uživatelů. Ta je založena na tom, že si tam v podstatě vedete CV online a jako reference používáte kolegy, se kterými jste pracovali nebo pracujete.

Pokud se zeptám 10 Java vývojářů, jak takovou aplikaci navrhnou naimplementují, tak odpověď 9 bude v kostce vypadat následovně. Použiju relační databázi, do ní namapauju entity pomocí Hibernate, transakce budu řídít přes Spring, bude tam DAO a servisní vrstva. Pro webovou vrstvu určitě MVC framework. Na otázku kde budou tohle řešení provozovat bezelstně odpoví, že na Google App Engine. Sice s tim nemají žádné zkušenosti, ale prý se na něm dá dobře škálovat.

Přesně tohle je Obrácený design, jsme posedlí technologiemi a vsrtvami aniž bychom se zaměřili na to co je podstatné. Slepě aplikujeme postupy, které jsme viděli a o kterých toho nejvíc víme a zdají se nám jako svaté. Stop, stop a ještě jednou stop. Vraťmě se na záčátek. Je potřeba protřepat hlavu a podívat se na ten problém od jeho základů.

Moje historická zkušenost mě vede k tomu, že aplikace se nenavrhují od středu, ale od spodku a hořejšku. Na začátku bychom si měli položit otázku, s jakými daty budeme pracovat a jaké operace na nich budeme chtít provádět. Budeme data spíš číst nebo zapisovat, jaký bude poměr zápisu a čtení. Máme jenom jeden typ dat a nebo máme různé kategorie. Jaký bude objem těch dat. Budu potřeba vyhledávat, bude potřeba dělat složité dotazy a nebo mi bude stačit CRUD. Jaká musí být konzistence dat, můžeme si dovolit "zvětralá" (stale) data.

Požadavky na operaci s daty do jisté míry napovídá cosi o tom, jak bude vypadat klient. Potřebujeme tlustého nebo tenkého klienta, budeme mít jenom jeden typ klienta nebo více. Chceme mít API pro integraci s dalšími službami. Kde budeme držet stav komunikace, můžeme si to dovolit na serveru. Jak velké objemy dat si můžeme dovolit přenášet vzhledem k rychlosti.

Pokud si odpovíme na výše uvedené otázky vypadnou nám celkem jasné požadavky nejenom na návrh střední vrstvy, ale i na konkrétní technologie, které nám budou vyhovovat. Dokonce tím získáme i odpověď na jaké infrastruktuře jsme schopni řešení hostovat. Ve skutečnosti pravděpodobně dojdete k tomu, že je úplně jedno jestli použijete Spring nebo Google Guice, protože to bude opravdu až ta poslední věc, která vás bude pálit.

Prosím ještě jednou nedesignovat od středu :-).