Butterfly Design Logo Butterfly Design Title
← Natrag na blog Arhitektura softvera • Legacy modernizacija

Clean Architecture: Zašto je korak dalje od slojevite arhitekture

Butterfly Design • Ivan Rendulić  ·  Svibanj 2026

Slojevita arhitektura je dobar temelj za svaki ozbiljan softverski projekt. Ali postoji jedan temeljni problem koji ju ograničava — i koji Clean Architecture elegantno rješava.

Problem slojevite arhitekture

Klasična slojevita arhitektura dijeli sustav na prezentacijski, poslovni i podatkovni sloj. To je već veliki korak naprijed od "špageti koda" gdje je sve pomiješano. Ali problem leži u smjeru ovisnosti.

Slojevita arhitektura

Gornji slojevi ovise o donjima. UI ovisi o poslovnoj logici, poslovna logika ovisi o bazi. Promjena baze može poremetiti cijeli sustav.

Clean Architecture

Ovisnosti su okrenute prema centru. Poslovna logika ne ovisi ni o čemu. Sve ostalo — UI, baza, framework — ovisi o njoj.

Zvuči kao detalj, ali u praksi je razlika ogromna.

Kako Clean Architecture funkcionira

U srcu Clean Architecture nalazi se poslovna logika — čista, izolirana, neovisna. Oko nje su slojevi koji implementiraju tehničke detalje: baza podataka, web framework, UI, vanjski servisi.

UI · Web framework · Baza · Vanjski servisi Infrastrukturni sloj
↓ ovisi o ↓
Use Cases · Application Services Aplikacijski sloj
↓ ovisi o ↓
Entiteti · Poslovna pravila Jezgra — ne ovisi ni o čemu

Ključno pravilo je jednostavno: ovisnosti uvijek idu prema centru, nikad prema van. Jezgra ne zna ništa o bazi, frameworku ni UI-u.

Što to znači u praksi

  • Možeš zamijeniti bazu podataka — poslovna logika ostaje netaknuta
  • Možeš promijeniti web framework — poslovna logika ostaje netaknuta
  • Možeš testirati poslovnu logiku bez pokretanja cijele aplikacije
  • Novi developer može razumjeti što sustav radi bez poznavanja tehničkih detalja

Zašto je ovo posebno vrijedno kod modernizacije

Kod legacy sustava, najveći problem nije zastarjela tehnologija — to se može zamijeniti. Najveći problem je poslovna logika zakopana u tehničkim detaljima. SQL upiti koji sadrže poslovne odluke. UI kod koji validira poslovne iznimke. Ono što bi trebalo biti u jezgri raštrkano je po cijelom sustavu.

Kroz softversku forenziku rekonstruiramo tu poslovnu logiku i smještamo je u zaštićenu Clean Architecture jezgru. Kad je jednom tamo — možemo slobodno mijenjati sve ostalo. Novu bazu, novi UI, novi framework. Jezgra ostaje stabilna.

"The goal of Clean Architecture is to minimize the human resources required to build and maintain software."

— Robert C. Martin (Uncle Bob)

Manje resursa za održavanje znači niže troškove. Stabilna jezgra znači dugovječniji sustav. A mogućnost zamjene tehničkih detalja znači slobodu da pratite promjene u tehnologiji bez da svaki put pišete sustav iznova.

Clean Architecture i Repository Pattern — savršen par

Clean Architecture definira što jezgra smije znati — ništa o tehničkim detaljima. Repository Pattern definira kako se ti detalji apstrahiraju — kroz sučelje koje jezgra koristi, a infrastrukturni sloj implementira.

Zajedno čine temelj svake ozbiljne modernizacije. Jezgra je stabilna i testabilna. Infrastruktura je zamjenjiva. Migracija je postupna i sigurna.

Kod koji razumije samo jedan čovjek nije imovina — to je rizik.
Clean Architecture mijenja tu jednadžbu.

Imate legacy sustav koji nitko više ne razumije? Razgovarajmo.

Zatraži besplatnu procjenu