Ivan Pavić
Autor:
Ivan Pavić

C#.Net developer, Scrum master

Entity models, the VB6 legacy

Zadnjih godina Microsoft je napravio veliki zaokret od Drag and Drop paradigme programiranja i uložio veliki trud da svoj development stack pogura u drugom smjeru. U svjetlu tog zaokreta kao najistaknutiji član došao nam je MVC Framework kao veliki hit (iako MVC kao design pattern postoji vec 30-ak godina) te povukao u mainstream i druge patterne. Danas u .NET  zajednici gotovo da i nema osobe koja ne zna šta su UnitOfWork, Repository, Strategy... da ne spominjem SoC ili SRP.

O tim stvarima se svakodnevno mudruju mudrosti u sklopu Backlog Groominga, Sprint retrospektiva, ručkova, kava... Nemojte me krivo shvatiti, nemam ništa protiv toga.

Ali gdje su modeli?

Kada mudra rasprava dovede do teme modeliranja apstrakcije realne poslovne domene, rasprave prestaju. Jeli opće razmišljanje da je tu sve jednostavno, jasno i čisto ili je tema preteška za casual razgovore?

Mišljenja sam (… a znamo šta je mišljenje) da je u pitanju ovo prvo. Zaključujem to jer sam svakodnevno vidim primjere dehidriranih modela sustava. Anemic model; hrpa klasa sa hrpama public Property-ja bez trunke enkapsulirane poslovne logike.

Poslovna logika je raštrkana po storanim procedurama, servisima, JavaScript funkcijama (ili još bolje JQuery event handlerima), na Button_click eventima i sl.. Jeli to neki Distribution Of Concerns (DoC) Pattern?  Toliko vremena trošimo kako bi svoje projekte oplemenili modernim tehnologijama, da bi razvijali na modernim principima, a zaboravljamo jedan elementarni. Kao da od drveća ne vidimo šumu. Mudrujemo oko trivijalnih dijelova sustava, koje možemo ionako refactorirati ili potpuno zamijeniti u 2 dana, a zanemorujemo najvažniji dio sustava. Možda mi zato modeli kompleksnih sustava djeluju (opet mišljenje) kao napuhani primjeri Microsoft Demo aplikacija tipa: Pogledajte kako sa našim novim frameworkom u 2 sata napravite YouTube ili Facebook.

Najveća kvaka ovakvog modeliranja jest to što ona naizgled daje rezultate. Istina, u par sati imate working model i prvi Product Backlog Item u statusu Done. Product Owner je presretan. Problemi nastaju kasnije, kada je prekasno (čitaj preskupo) razmišljati o promjeni/zamjeni arhitekture. Kolega je baš na blogu napisao članak u kojem spominje stepenice kompleksnosti. Svakim prelaskom na novu stepenicom sustav građen Anemic model pristupom postaje eksponencijalno teži za održavanje, eksponencijalno teži za testiranje i nestabilniji što u konačnici vodi do neodrživog sustava ili održivog uz jako visoku cijenu. Ako već neće biti neodrživ, biti će neisplativ. Product Owner više nije presretan.

Zašto se to dešava?

Zato što niti jedan dehidrirani entitet nije u stanju validirati svoje stanje, ne zna zašto je instanciran, što on ustvari treba napraviti. Takav entitet ne definira što je on u stanju napraviti niti može nametnuti pravila pod kojima se neka operacija treba izvršiti.  On je običan kofer koji ima neki svoj sadržaj i putuje tako od mjesta do mjesta. Inače,  posao kofera je da svoj sadržaj uredno zadrži u sebi i da se ne raspadne prije dolaska na cilj. Drugi su zaduženi da se brinu o tome kuda on ide i kako će tamo stići. Za jedan običan kofer to ne predstavlja problem jer oni koji s njime barataju u transportu ne trebaju njegov sadržaj. Njegov sadržaj se validira tek prilkom dolaska na odrediše prilikom raspakiravanja.

U Anemic Model sustavima kofer dođe na checkpoint (servis) koji onda taj kofer otvara, gleda što se u njemu nalazi i na temelju toga odlučuje što sa tom hrpom prljavog veša treba napraviti. Servis mora pregledati gotovo svaki djelić i sam utvrditi dali je to čisti/zmazani/miješani veš? Jel skup, ukraden, muški/ženski… Servis ove provjere mora raditi sekvencijalnim operacijama što generira puno proceduralnog koda, hrpu If-ova (branch-anja koda). Sa svakim novim pretincem unutar kofera ovaj broj provjera raste. Problem je tim veći što se servisi obično ne brinu samo za kofere, nego i za vrećice, kutije, kuverte i sl.  Servis se tako vrlo brzo pretvara u nečitljiv sadržaj kojim su donekle sposobni upravljati samo ljudi koji su taj proceduralni monolit stvorili.

 

Alternativa?

Korištenje Domain Modela (Rich Domain Model) može u velikoj mjeri riješiti probleme ove prirode. Domain model nije nikakva novotarija. Knjiga Martina Fowlera iz 2002. g. koja se u jednom dijelu bavi modelima i Domain-driven design (DDD) pristup koji je počeo sa knjigom Ricka Evansa 2003. g. su pristutni već cijelo desetljeće i gotovo su postali standardan pristup u rješavanju problematike komplekstih sustava. Ako uzmemo za primjer kofere iz prethodnog paragrafa, pravi domenski kofer bi znao što se sve u njemu nalazi. Znao bi dali je napunjen, sa čime je napunjen i sam bi određivao što se njim može napraviti. Na taj način, on ne prisiljava svakog nostelja (servis) da ga otvara i gleda što je u njemu. On čak zna i sam raspakirati. Servis mu je potreban samo da ga prenese do odredišta i da mu kaže na kojem mjestu će se raspakirati. Ako mu uvjeti raspakiravanja ne pašu, odbit će poslušnost. Takav model, da parafraziram gosp. Evansa, je sposoban preuzeti odgovornost za rješavanje kompleksnosni u srcu softvera.

 

Da se razumijemo, prelazak na Rich-Domain model, pogotovo na DDD, nije lagan zadatak. Traži upfront investiciju na projektu i dobro poznavanje. Nije niti potreban na svakom projektu. Mali web shop-ovi čiji razvoj traje par mjeseci i koji nakon toga pređu u mod održavanja vjerojatno nisu kandidati za ovakav pristup, ali projekti koji traju godinama, koji se stalno nadograđuju…

Uostalom, čak i da jednostavan projekt nepotrebno napravite po DDD načelima, radi se samo o nepotrebnom upfront trošku, a steći ćete jedno dobro iskustvo koje možete iskoristiti na nekom stvarno kompleksnom sustavu. Kada se jednom dignete iz podruma infrastrukture, posložite agregate, repozitorije i ostalo, put dalje je isti ili lakši nego sa primjenom Anemic modela. Ako ste još k tome ispravno identificirali Core-Domain, i našli ubiquitous language….

 

Opet jedno mišljenje (ako ti se nisu dopala prethodna, neće ti se niti ovo)

Čini mi se da je takav način rada (govorim o Entity modelu) legacy jednog prošlog doba u kojem je jedini dio sustava koji je nalikovao nekakvom modelu bila baza podataka, a ujedno i jedina shema sustava. Jedina integracijska točka. Možda je Microsoft sam tome pridonio gurajući Drag and Drop retoriku gdje je dovoljno samo povući Bazinga kontrolu na neku Bazinga formu i  ta daaaa !!! Kontrola će implemenitari svu logiku i infrastrukturu, a vi samo podesite par propertyja (With just few lines of code…). Jesu li zbilja i oni mislili  da će to funkcionirati na velikim projektima ili smo to mi krivo protumačili?

 

Ako nekoga zanima preporuka za štivo:

 

Popularne teme
.NET ABAP ADFS Agile Always On Anemic Model Angular Azure Backbone BI BI projekti Bootstrap building people business inteligence Business Intelligence Change Chrome CI CITCON Claims compile Continuous Delivery continuous deployment Continuous Integration CSR d3js data data visualization Data visualization alati DDD dekompozicija dependency injection dinamička forma dinamički parametri dinamički query distribuirani razvoj Domain-Driven design DOP društvena odgovornost edge-based video analytics Eliminating waste enkapsulacija enterprise razvoj softvera ERP ETL Excel FIORI Frontend game Geopackage GPKG GIS Git Groovy heat map HICCUPS Hichert HTML IBCS interoperability invision IoT IPSO izvještavanje java java lambde benchmark JavaFX Javascript Jazz Build Engine JBE Jenkins jquery jqueryui jsfiddle JVM Kaizen Kanban KING ICT Kingovci Knockout kvaliteta leadership Lean M language Management Maven Metodologija microservices Microsoft mobile Mobility mockups moć monday game NetWeaver network nodejs OGC OKR open source optimizacija organizacija organizacijska struktura OutOfMemoryError outsourcing paginacija Performance performanse PERT PMI podatkovni skup pouzdanost Power BI Power Map Power Pivot Power Query Power View pretraga proces procjena Product Owner programming proizvod Project manager projektni plan radar Rational Team Concert razvoj tima Release resize responsive charts REST retrospektiva Rich-Domain model Roko Roić rolling wave planning RTC SAP scale scatterplot chart Scrum scrum team scrum tim service boundaries single responsibility principle Single Sign-On smart metering SoapUI social responsibility softver Software software prototyping Software Testing Club Spring Boot SQL standard sustav videonadzora svg Team team building team development Team Foundation Server terminski plan Testing tim timesheet timovi Toggl.com touch transakcijski nadzor tražilica Uspjeh Visual Studio vodstvo vodstvo leadership moć društvena odgovornost DOP social responsibility CSR vođenje projekata WBS Web Zagreb STC

PRIJAVA NA NEWSLETTER

Najnovije novosti iz ICT svijeta