Aina tulisi pyrkiä modulaariseen suunnitteluun, mutta onko tilanteeseen sopiva spesifi ratkaisu sittenkään aina pahasta?
Sprintin deadline paukkuu, mutta tuotannosta on löytynyt A-luokan suorituskykyyn liittyvä bugi, joka tulisi korjata välittömästi. Kaikki Sprintissä tapahtuva työ tulee jättää taka-alalle ja lähteä selvittämään bugia.
Bugi löytyy lopulta kohdasta, jossa käyttäjän tekemä REST-kutsu hakee palvelimelta liikaa tietoa UI-kerrokselle, vaikka varsinainen käyttötapaus ei tarvitsisi puoliakaan palvelimella koostetusta oliolistahierarkiasta. Chromen verkkovälilehdeltä nähdään, että yhden kutsun kooksi muodostuu 20 megatavua!
Spesifi ratkaisu
Devaaja korjaa ylläolevan ongelman poistamalla vastausoliosta kentät, joita kyseinen käyttötapaus ei tarvitse. Näin ollen REST-vastaus kutistuu 5 megatavun kokoiseksi, mikä juuri ja juuri riittää nopean nettiyhteyksien omaaville loppuasiakkaille tyydyttämään vasteajan.
Devaajalta jää kuitenkin kiireessä huomioimatta se, että vaikka vastausoliosta on poistettu tarpeettomat lisäkentät, kyseisiä kenttiä tarvitaan sovelluksen muissa osissa. Varsinainen REST-kutsu on itse asiassa rakennettu geneeriseksi, jotta samaa asiaa ei tarvitse koodata useaan kertaan ja taustajärjestelmän API-kutsu voisi näin ollen palvella useaa eri käyttötapausta.
Kun hotfix on asennettu tuotantoon, asiakkaat huomaavat puutteellisen toiminnallisuuden muissa samaa REST-kutsua käyttävissä näytöissä, jossa kaikki tiedot eivät välity näytölle. Kysei
Esimerkkini kuvaa reaalimaailman ongelmaa ja on vain yksi tapaus siitä, kuinka ongelmista pyritään pääsemään eroon laittamalla ns. purkkaa väliin. Todellinen ongelma oli kuitenkin siinä, että jokainen samaa oliomallia käyttävä käyttötapaus noutaa mallissa viitatun tiedoston mukanaan käyttöliittymäkerrokselle. Tämä on aika klassinen huomaamaton suunnitteluvirhe kokemattomalta devaajalta, jos ORM-mallina on vaikkapa Hibernate.
Entä oikeat spesifit ratkaisut?
Asiaa voidaan lähestyä toisesta näkökulmasta. Toteutettaessa erillistä, itsenäistä sovelluskokonaisuutta speifit ratkaisut ovat perusteltuja.
Jos mietitään mikropalveluita, joissa itsenäiset komponentit ovat erillisinä osia, jokaisen palvelukomponentin tehtävänä on täyttää sille kuuluva liiketoiminnallinen tarve. Mallin tavoitteena on suunnitella komponentteja niin tarkasti, ettei keskinäisiä riippuvuuksia toisiinsa tule ja jos tulee, ne on kuvattu mahdollisimman löyhästi rajapintojen avulla. Voidaan ajatella, että yksittäisellä mikropalvelulla on fokusoitu, yhden käyttötarkoituksen omaava tehtävä, jossa komponentti toteutta SRP (single–responsibility principle) mukaisen paradigman. Esimerkiksi logitusmikropalvelu toteuttaa logien kirjoittamisen, palkanmaksupalvelu palkanmaksamisen tai tulostuspalvelu tulostamisen. Näin ollen yksittäisen palvelun muutostarpeisiin vastaaminen ja ylläpito on melko turvallista johtuen palvelun spesifistä luonteesta.
Geneerisyys comes to rescue?
fffffffffff