[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:sr":3,"public-menus:all":38,"post:model-view-controller-mvc:sr":205,"related:post:model-view-controller-mvc:sr:1":876},{"statusCode":4,"data":5,"message":37},200,{"tenantId":6,"lang":7,"defaultLang":8,"siteUrl":9,"contactEmail":10,"brandName":11,"logoUrl":12,"siteName":11,"siteDescription":13,"ogImage":10,"robotsIndex":14,"socialLinks":10,"reservedSlugs":10,"seoPolicy":15},"stajic","sr","de","https:\u002F\u002Fstajic.de",null,"Stajic Platform","\u002FLogo_Planet.svg","Stajic Portal",true,{"branding":16,"relatedContent":17,"crossDomainLinks":18},{"logoUrl":12},{"enabled":14},[19,22,25,28,31,34],{"url":20,"label":21,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Ffigure.rocks","figure.rocks",{"url":23,"label":24,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Floving.rocks","loving.rocks",{"url":26,"label":27,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.com","bazify.com",{"url":29,"label":30,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.de","bazify.de",{"url":32,"label":33,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.at","bazify.at",{"url":35,"label":36,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.ba","bazify.ba","Portal settings resolved",[39,45],{"id":40,"name":41,"location":42,"isActive":14,"isDefault":43,"items":44},1,"main-navigation","header",false,[],{"id":46,"name":47,"location":48,"isActive":14,"isDefault":14,"items":49},4,"main-menu","sidebar",[50,66,79,93,103,118,133],{"id":51,"title":52,"url":60,"target":61,"icon":62,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":64,"portfolioId":10,"children":65},"item-18",{"de":53,"en":54,"es":55,"fr":56,"it":54,"ru":57,"sr":58,"zh":59},"Startseite","Home","Inicio","Accueil","Главная","Почетна","首页","\u002Ffull-stack-web-developer-munich-performance-seo-and-maintainable-builds","_self","i-lucide-home","page",111,[],{"id":67,"title":68,"url":75,"target":61,"icon":76,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":77,"portfolioId":10,"children":78},"item-22",{"de":69,"en":69,"es":70,"fr":69,"it":71,"ru":72,"sr":73,"zh":74},"Vision","Visión","Visione","Видение","Визија","想象","\u002Fueber-uns-webdesign-muenchen-webaplikation","i-lucide-eye",113,[],{"id":80,"title":81,"url":89,"target":61,"icon":90,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":91,"portfolioId":10,"children":92},"item-19",{"de":82,"en":83,"es":84,"fr":83,"it":85,"ru":86,"sr":87,"zh":88},"Leistungen","Services","Servicios","Servizi","Услуги","Услуге","服务","\u002Fservices-dienstleistungen-muenchen","i-lucide-wrench",116,[],{"id":94,"title":95,"url":99,"target":61,"icon":100,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":101,"portfolioId":10,"children":102},"item-23",{"de":96,"en":96,"es":96,"fr":96,"it":96,"ru":97,"sr":97,"zh":98},"Blog","Блог","博客","\u002Fblog","i-lucide-book-open",112,[],{"id":104,"title":105,"url":114,"target":61,"icon":115,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":116,"portfolioId":10,"children":117},"item-32",{"de":106,"en":107,"es":108,"fr":109,"it":110,"ru":111,"sr":112,"zh":113},"Neue Technologien","New Technologies","Nuevas tecnologías","Nouvelles technologies","Nuove tecnologie","Новые технологии","Нове технологије","新技术！","\u002Fneue-webtechnologien","i-lucide-sparkles",122,[],{"id":119,"title":120,"url":129,"target":61,"icon":130,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":131,"portfolioId":10,"children":132},"item-20",{"de":121,"en":122,"es":123,"fr":124,"it":125,"ru":126,"sr":127,"zh":128},"Kontakt","Contact us!","Contacto","Contact","Contatto","Контакт","Контактирајте нас","联系我们！","\u002Fcontact","i-lucide-mail",115,[],{"id":134,"title":135,"url":144,"target":61,"icon":145,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":147},"item-21",{"de":136,"en":137,"es":138,"fr":139,"it":140,"ru":141,"sr":142,"zh":143},"Unsere Arbeit","Our Work","Nuestro trabajo","Nos réalisations","I nostri lavori","Наши работы","Наши радови","文件夹","\u002Fportfolio","i-lucide-briefcase",114,[148,161,175,181,193],{"id":149,"title":150,"url":144,"target":61,"icon":159,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":160},"item-24",{"de":151,"en":152,"es":153,"fr":154,"it":155,"ru":156,"sr":157,"zh":158},"Alle Projekte","All Projects","Todos los proyectos","Tous les projets","Tutti i progetti","Все проекты","Сви пројекти","所有项目","i-lucide-grid-3x3",[],{"id":162,"title":163,"url":171,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":174},"item-29",{"de":164,"en":165,"es":166,"fr":167,"it":168,"ru":169,"sr":170,"zh":143},"Local Roots, Global Reach","Local Roots - Global Reach","Empresa local ","Entreprise locale","Azienda locale","Местная компания","Локално предузеће глобално тржиште","\u002Fportfolio\u002Flocal-roots-global-reach-communication-media-systems-for-modern-business","i-lucide-folder","custom",[],{"id":176,"title":177,"url":179,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":180},"item-28",{"de":178,"en":178,"es":178,"fr":178,"it":178,"ru":178,"sr":178,"zh":178},"Solr Suggester","\u002Fportfolio\u002Fsolr-fuzzy-suggester-und-solr-infix-suggester-abfrage-ueber-ajax-und-filterung",[],{"id":182,"title":183,"url":191,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":192},"item-27",{"de":184,"en":185,"es":186,"fr":187,"it":188,"ru":189,"sr":190,"zh":185},"Firmenwebseite SEO","Company Website SEO","Sitio web corporativo SEO","Site web d’entreprise SEO","Sito web aziendale SEO","Корпоративный сайт SEO","Пословна веб-страница SEO","\u002Fportfolio\u002Fseo-sem-branding-mobile-webseite-muenchen",[],{"id":194,"title":195,"url":203,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":204},"item-31",{"de":196,"en":197,"es":198,"fr":199,"it":200,"ru":201,"sr":202,"zh":197},"Digitalisierungsportal","Digitalization Portal","Portal de digitalización","Portail de numérisation","Portale di digitalizzazione","Портал цифровизации","Портал за дигитализацију","\u002Fportfolio\u002Fdigitalisierungsportal-archiv-museum-bibliothek-ead-lido-mets-mods",[],{"statusCode":4,"data":206,"message":875},{"id":207,"title":208,"slug":209,"content":210,"contentJson":211,"excerpt":457,"featuredImage":458,"featuredImageAlt":459,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":460,"publishedAt":461,"createdAt":462,"updatedAt":463,"seoLocalePaths":464,"categories":473,"author":485,"translations":490},"361","Model-View-Controller (MVC): Strukturna okosnica modernih veb aplikacija","model-view-controller-mvc","\u003Cp>\u003Cb>Model-View-Controller (MVC)\u003C\u002Fb> obrazac ostaje jedan od najizdržljivijih temelja u arhitekturi veb aplikacija. Njegova dugovečnost nije slučajna. MVC opstaje jer rešava problem koji nikada zapravo ne nestaje: kako strukturirati softver tako da rast ne pretvori svaku promenu u rizik. Kada su odgovornosti dobro razdvojene, timovi mogu proširivati funkcionalnosti, revidirati interfejse, refaktorisati unutrašnjost i objavljivati promene sa daleko manje trenja.\u003C\u002Fp>\n\u003Cp>Zato ova tema prirodno pripada unutar \u003Cb>Enterprise Delivery OS\u003C\u002Fb>-a. MVC nije samo konvencija kodiranja. To je strukturna disciplina koja utiče na održivost platforme, bezbednost isporuke, napor pri migraciji, dizajn testova i operativnu jasnoću. U praktičnom inženjerskom smislu, MVC je koristan jer postavlja granice tamo gde se sistemi obično zapetljaju.\u003C\u002Fp>\n\u003Cp>Unutar stajic.de strukture stubova, najjače primarno uklapanje je \u003Cb>Referentni modeli > Digitalna platforma\u003C\u002Fb>. MVC je prvenstveno tema arhitekture i granica platforme. Takođe se povezuje sa isporukom i promenama, migracijom i replatformisanjem, kontrolom izdanja i procenom isporuke, ali to su sekundarni prateći odnosi, a ne glavna klasifikacija.\u003C\u002Fp>\n\u003Ch2>Šta MVC zapravo razdvaja\u003C\u002Fh2>\n\u003Cp>MVC deli aplikaciju na tri različite oblasti odgovornosti. \u003Cb>Model\u003C\u002Fb> predstavlja stanje domena, invarijante i pravila. \u003Cb>View\u003C\u002Fb> je odgovoran za prezentaciju i interakciju. \u003Cb>Controller\u003C\u002Fb> prima zahteve, koordinira relevantan slučaj korišćenja i odlučuje kako odgovor treba da bude sastavljen. Nazivi su jednostavni, ali je vrednost značajna: čisto razdvajanje smanjuje skrivenu spregnutost.\u003C\u002Fp>\n\u003Cul>\u003Cli>\u003Cb>Model\u003C\u002Fb> poseduje domensko značenje, a ne samo skladištenje podataka.\u003C\u002Fli>\u003Cli>\u003Cb>View\u003C\u002Fb> jasno predstavlja informacije, a da pritom tiho ne postane poslovni sloj.\u003C\u002Fli>\u003Cli>\u003Cb>Controller\u003C\u002Fb> koordinira tok, umesto da se pretvori u 'god object'.\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Kada te granice oslabe, sistemi postaju teži za razumevanje. Poslovna pravila skliznu u šablone (templates). Kontroleri postaju preopterećeni orkestracijom, validacijom i sporednim efektima. Modeli postaju pasivni omotači baze podataka. Timovi tada mešaju strukturu radnog okvira sa arhitektonskom jasnoćom, iako je kodna baza već zapetljana.\u003C\u002Fp>\n\u003Ch2>Zašto je MVC i dalje važan u modernim veb stekovima\u003C\u002Fh2>\n\u003Cp>Moderni radni okviri često govore drugačijim jezikom: komponente, composables, ostrva (islands), serverske akcije, API rute, headless isporuka i edge renderovanje. Ništa od toga ne uklanja potrebu za razdvajanjem. To samo redistribuira mesta gde se razdvajanje mora dogoditi. Ozbiljna platforma i dalje treba stabilno mesto za domenska pravila, kontrolisanu putanju za orkestraciju zahteva i prezentacioni sloj koji tajno ne poseduje polisu.\u003C\u002Fp>\n\u003Cp>Zato korisno pitanje nije da li se radni okvir naziva MVC-om. Korisno pitanje je da li platforma štiti iste one granice koje je MVC dizajniran da sprovodi. Ako to ne čini, onda stek može izgledati moderno dok i dalje akumulira strukturni dug.\u003C\u002Fp>\n\u003Cblockquote class=\"border-l-4 border-gray-300 pl-4 italic\">Novina radnog okvira ne zamenjuje arhitektonsku disciplinu. Nova sintaksa može sakriti stari haos.\u003Ccite class=\"block mt-2 text-sm\">— Perspektiva arhitekture platforme\u003C\u002Fcite>\u003C\u002Fblockquote>\n\u003Ch2>Minimalni tok zahteva\u003C\u002Fh2>\n\u003Cp>Najjednostavniji način da razumete MVC je da pratite zahtev kroz sistem. Korisnik zahteva stranicu ili pokreće akciju. Kontroler prima zahtev, delegira domenski rad modelima ili servisima, priprema strukturu odgovora i prosleđuje rezultat pogledu (view). Pogled renderuje izlaz. Ovaj tok je lako objasniti, ali ga mnogi sistemi krše u praksi.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>\u002F\u002F Zahtev ulazi u sistem\nGET \u002Fproducts\u002F42 \u002F\u002F Ruter bira akciju kontrolera\nProductController.show(id = 42) \u002F\u002F Kontroler koordinira slučaj korišćenja\nproduct = ProductService.getById(42)\nviewModel = ProductPresenter.toViewModel(product) \u002F\u002F View renderuje izlaz\nreturn render("product\u002Fshow", viewModel)\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Ovaj primer je namerno minimalan. Vrednost nije u sintaksi. Vrednost je u vidljivosti. Recenzent može da vidi gde zahtev ulazi, gde se odvija domenski rad i gde počinje prezentacija. Ta jasnoća postaje izuzetno važna kada timovi menjaju živu platformu pod pritiskom isporuke.\u003C\u002Fp>\n\u003Ch2>Šta bi Model zaista trebalo da poseduje\u003C\u002Fh2>\n\u003Cp>U slabim implementacijama, model postaje malo više od ORM entiteta ili zapisa u bazi podataka. To je previše usko. Koristan model štiti poslovno značenje. On treba da sadrži pravila koja moraju ostati tačna bez obzira na to da li je zahtev došao iz veb forme, admin ekrana, javnog API-ja, pozadinskog radnika ili CLI posla.\u003C\u002Fp>\n\u003Cul>\u003Cli>Tranzicije stanja, kao što su dozvoljene promene statusa\u003C\u002Fli>\u003Cli>Invarijante koje moraju važiti kroz svaki interfejs\u003C\u002Fli>\u003Cli>Validacija na nivou domena koja pripada poslovanju, a ne samo sloju forme\u003C\u002Fli>\u003Cli>Izračunate vrednosti i odluke koje predstavljaju stvarno poslovno ponašanje\u003C\u002Fli>\u003C\u002Ful>\n\u003Cpre class=\"code-block\">\u003Ccode>class Order: def cancel(self, actor): if self.status == "shipped": raise DomainError("Shipped orders cannot be cancelled") if not actor.can("cancel_order"): raise PermissionError("Actor may not cancel this order") self.status = "cancelled"\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>To pravilo je malo, ali je lekcija velika. Ako je pravilo važno, potreban mu je stabilan dom. Kada takva logika postoji samo u jednoj akciji kontrolera ili jednoj UI formi, drugi put će je na kraju zaobići. Domenska pravila treba da žive tamo gde domen može zapravo da ih odbrani.\u003C\u002Fp>\n\u003Ch2>Šta bi pogled (View) trebalo, a šta ne bi trebalo da radi\u003C\u002Fh2>\n\u003Cp>Pogled postoji da bi predstavio informacije, formatirao izlaz i podržao interakciju. Može sadržati logiku prikaza, ali ne bi trebalo da postane skriveni vlasnik važne poslovne politike. Kada šabloni počnu da odlučuju o tome kome je šta dozvoljeno, sistem postaje teži za testiranje, teži za reviziju i lakši za kvarenje.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode><!-- Dobro: logika prezentacije -->\n{% if product.stock > 0 %} <button>Dodaj u korpu<\u002Fbutton>\n{% else %} <p>Trenutno nedostupno<\u002Fp>\n{% endif %} <!-- Loše: poslovna politika curi u šablon -->\n{% if user.role == "admin" or order.total < 1000 or region == "DE" %} <button>Odobri povraćaj<\u002Fbutton>\n{% endif %}\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Pogled može odlučiti kako da prikaže stanje. Ne bi trebalo da tiho odlučuje o tome koje su politike važeće. Ta razlika izgleda mala u pregledu koda, ali vremenom postaje ogromna.\u003C\u002Fp>\n\u003Ch2>Kontroleri treba da koordinišu, a ne da akumuliraju moć\u003C\u002Fh2>\n\u003Cp>Kontroleri su korisni jer stvaraju jasan ulaz u aplikaciju. Ali treba da ostanu fokusirani. Kontroler koji validira sirove podatke, poziva eksterne servise, izračunava domenske odluke, transformiše podatke za perzistenciju i odlučuje o konačnoj strategiji renderovanja više nije samo kontroler. On postaje skriveni sloj aplikacije zavaren za HTTP.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>\u002F\u002F Previše odgovornosti u jednom kontroleru\nasync function checkout(req, res) { validateCart(req.body) const tax = await taxApi.calculate(req.body.address, req.body.items) const discount = computeDiscount(req.user, req.body.items) const inventory = await reserveItems(req.body.items) const payment = await chargeCard(req.body.card) const order = await db.orders.create({ tax, discount, inventory, payment }) res.render("checkout\u002Fsuccess", { order })\n}\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cpre class=\"code-block\">\u003Ccode>\u002F\u002F Bolje: kontroler delegira aplikacionim servisima\nasync function checkout(req, res) { const command = CheckoutCommand.fromHttp(req) const result = await checkoutService.execute(command) res.render("checkout\u002Fsuccess", CheckoutPresenter.toViewModel(result))\n}\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Ovde MVC postaje snažno relevantan za kvalitet isporuke. Jasne granice smanjuju obim pregleda, umanjuju uticaj promena i olakšavaju razumevanje izdanja. To je takođe razlog zašto se MVC prirodno povezuje sa \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change\">Referentnim modelom isporuke i promena\u003C\u002Fa>, koji se fokusira na bezbedno slanje promena uz eksplicitne dokaze i merljive ishode.\u003C\u002Fp>\n\u003Ch2>MVC i arhitektura platforme\u003C\u002Fh2>\n\u003Cp>Najbolje primarno uklapanje za ovaj članak je \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Freference-models\u002Fdigital-platform\">Referentni model digitalne platforme\u003C\u002Fa>. Ta stranica opisuje strukturu nezavisnu od tehnologije za dizajniranje i upravljanje digitalnom platformom u velikom obimu. MVC se tu uklapa jer je deo strukturnog rečnika koji timovi koriste za definisanje granica, odgovornosti i površina promena unutar stvarnih sistema.\u003C\u002Fp>\n\u003Cp>Platforma sa slabim unutrašnjim granicama može i dalje raditi u produkciji, ali postaje sporija za evoluciju. Nove funkcionalnosti traju duže. Bagove postaje teže lokalizovati. Refaktorisanje se odlaže. Izdanja nose više nepoznatog rizika. U tom smislu, MVC nije samo stvar stila koda. Radi se o očuvanju promenljivosti.\u003C\u002Fp>\n\u003Ch2>MVC u modernim okvirima i headless sistemima\u003C\u002Fh2>\n\u003Cp>Ne izlaže svaki moderni stek klasični MVC direktno. U SSR okvirima, kontroleri se mogu pojaviti kao rukovaoci rutama ili serverske akcije. U API-first sistemima, prikaz (view) može živeti u zasebnom frontendu. U headless platformama, ponašanje modela može biti podeljeno na servise, domenske module i slojeve perzistencije. Ali potreba za razdvajanjem ne nestaje. Ona se jednostavno širi na više pokretnih delova.\u003C\u002Fp>\n\u003Cul>\u003Cli>SSR okviri često pomeraju logiku kontrolera u rukovaoce na nivou rute\u003C\u002Fli>\u003Cli>API-first arhitekture postavljaju prezentaciju u poseban frontend sloj\u003C\u002Fli>\u003Cli>Headless sistemi distribuiraju ponašanje modela preko granica servisa i domena\u003C\u002Fli>\u003Cli>UI zasnovan na komponentama i dalje ima koristi od držanja poslovne politike van sloja prikaza\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Dakle, dublja pouka je sledeća: MVC ostaje vredan čak i kada njegovo klasično pakovanje nestane. On opstaje kao princip dizajna jer razdvajanje odgovornosti ostaje jedna od retkih pouzdanih odbrana od entropije.\u003C\u002Fp>\n\u003Ch2>Zašto MVC olakšava promenu platforme\u003C\u002Fh2>\n\u003Cp>Migracije nasleđenih sistema često ne uspevaju jer je stara platforma sve pomešala. Upiti se nalaze u šablonima. Prelazi stanja su sakriveni u pomoćnim datotekama. Validacija je duplirana u formama, API-jima i administratorskim alatima. Niko ne može bezbedno da pomeri jedan deo jer je previše odgovornosti spojeno. Što je razdvajanje čistije, to put migracije postaje realističniji.\u003C\u002Fp>\n\u003Cp>Zato MVC ima snažnu sekundarnu važnost za \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform\">Priručnik za migraciju i promenu platforme\u003C\u002Fa>. Promena platforme nije samo vežba zamene tehnologije. To je vežba razmrsivanja. Timovi moraju da izlože i stabilizuju granice odgovornosti pre nego što prelazak postane bezbedan.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>Redosled bezbedan za promenu platforme\n1. Izmestite domenska pravila iz šablona i kontrolera\n2. Svedite kontrolere na mapiranje zahteva i orkestraciju\n3. Uvedite prezentere ili modele pogleda za stabilne izlazne ugovore\n4. Izolujte pristup perzistenciji iza servisa ili repozitorijuma\n5. Migrirajte jednu po jednu granicu umesto da prepisujete sve odjednom\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Ova vrsta restrukturiranja ne čini migraciju trivijalnom, ali smanjuje neizvesnost. To samo po sebi može uštedeti mesece nepotrebnog rada.\u003C\u002Fp>\n\u003Ch2>Bezbednost izdanja, testiranje i operativno poverenje\u003C\u002Fh2>\n\u003Cp>MVC sam po sebi ne garantuje bezbedna izdanja, ali znatno olakšava postizanje bezbednosti izdanja. Tanki kontroleri, eksplicitni servisi, stabilni modeli pogleda i zaštićena domenska pravila čine jasnijim gde promena zaista utiče. To poboljšava kvalitet pregleda koda, sužava opseg grešaka i pomaže timovima da dizajniraju testove na odgovarajućem sloju.\u003C\u002Fp>\n\u003Cul>\u003Cli>Testovi modela proveravaju invarijante i poslovna pravila\u003C\u002Fli>\u003Cli>Testovi servisa proveravaju ponašanje slučajeva korišćenja\u003C\u002Fli>\u003Cli>Testovi kontrolera proveravaju mapiranje zahteva i tok odgovora\u003C\u002Fli>\u003Cli>Testovi pogleda proveravaju očekivanja renderovanja i interakcije\u003C\u002Fli>\u003Cli>End-to-end testovi štite ključne korisničke putanje bez nošenja celokupnog tereta\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Zbog toga se MVC prirodno povezuje sa \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Frunbooks\u002Frelease-runbook\">Priručnikom za izdanja\u003C\u002Fa> i \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment\">Procenom isporuke\u003C\u002Fa>. Platformu sa eksplicitnom strukturom je lakše objaviti, lakše meriti i lakše unaprediti.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>Obrazac promene bezbedan za objavljivanje\n1. Ažurirajte pravilo domena na jednom pouzdanom mestu\n2. Proširite testove servisa ili slučajeva korišćenja\n3. Prilagodite mapiranje kontrolera samo ako se promenio ugovor zahteva\n4. Ažurirajte prezenter ili model prikaza samo ako se promenio izlazni ugovor\n5. Verifikujte pogođene ekrane i API odgovore\n6. Objavite uz svest o povratku na prethodnu verziju i jasne dokaze\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>Uobičajeni MVC anti-obrasci\u003C\u002Fh2>\n\u003Cul>\u003Cli>Debeli kontroleri koji tajno sadrže sloj aplikacije\u003C\u002Fli>\u003Cli>Pasivni modeli bez značajnog ponašanja domena\u003C\u002Fli>\u003Cli>Prikazi koji donose skrivene odluke o polisama\u003C\u002Fli>\u003Cli>Duplirana validacija na frontendu, backendu i administratorskim alatima\u003C\u002Fli>\u003Cli>Nema stabilne granice prezentera ili modela prikaza između domena i korisničkog interfejsa\u003C\u002Fli>\u003Cli>Konvencije radnog okvira pogrešno shvaćene kao arhitektura\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Ovi problemi se često pojavljuju postepeno, zbog čega ih timovi potcenjuju. Baza koda može izgledati organizovano spolja, a i dalje biti strukturno slaba iznutra.\u003C\u002Fp>\n\u003Cblockquote class=\"border-l-4 border-gray-300 pl-4 italic\">Radni okvir može generisati foldere. Ne može generisati dobre granice. Njih i dalje mora dizajnirati i braniti tim.\u003Ccite class=\"block mt-2 text-sm\">— Perspektiva Enterprise Delivery OS-a\u003C\u002Fcite>\u003C\u002Fblockquote>\n\u003Ch2>Optimalno pozicioniranje SEO stubova\u003C\u002Fh2>\n\u003Cp>Unutar Enterprise Delivery OS strukture, ovaj članak pripada \u003Cb>Referentnim modelima > Digitalna platforma\u003C\u002Fb>. To je ispravno primarno pozicioniranje jer se MVC suštinski bavi strukturom platforme i granicama odgovornosti. Njegovi sekundarni prateći linkovi pripadaju \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change\">Isporuka i promena\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform\">Migracija i replatformisanje\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Frunbooks\u002Frelease-runbook\">Priručnik za izdanja\u003C\u002Fa> i \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment\">Procena isporuke\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>To pozicioniranje nije kozmetičko. Ono govori portalu, uredniku i čitaocu gde tema strukturno pripada. MVC nije prvenstveno kontrolna lista za izdanja, niti prvenstveno taktika migracije, niti prvenstveno rubrika za procenu. To je pre svega princip dizajna platforme.\u003C\u002Fp>\n\u003Ch2>Završna perspektiva\u003C\u002Fh2>\n\u003Cp>Model-View-Controller ostaje relevantan jer softver ne postaje lakši samo zato što su radni okviri noviji. Timovima je i dalje potrebno stabilno mesto za domenska pravila, kontrolisana putanja za obradu zahteva i prezentacioni sloj koji ne uvlači poslovnu logiku u interfejs. Kada se pravilno koristi, MVC postaje više od istorijskog obrasca. On postaje praktičan instrument za čistije arhitekture, bezbednija izdanja, lakše migracije i jaču dugoročnu disciplinu isporuke.\u003C\u002Fp>\n\u003Cdiv class=\"ce-delimiter cdx-block my-8\">\u003C\u002Fdiv>\n\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Enterprise Delivery OS\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Baza znanja za preduzeća o platformama, isporuci, bezbednosti i usvajanju LLM-a.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Freference-models\u002Fdigital-platform\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Referentni model digitalne platforme\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Tehnološki agnostička struktura za dizajniranje i upravljanje digitalnom platformom koja podržava isporuku proizvoda u velikom obimu.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Referentni model isporuke i promena\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Ovaj model definiše kako bezbedno isporučiti promene uz kontrolne tačke kvaliteta, jasne dokaze i merljive rezultate.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Priručnik za migraciju i promenu platforme\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Priručnik za smanjenje rizika migracije i strukturiranje bezbednijeg rada na promeni platforme.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Frunbooks\u002Frelease-runbook\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Operativni priručnik za izdanja\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Operativni priručnik za provere pre objavljivanja, korake izdanja, verifikaciju i pregled nakon izdanja.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Procena isporuke\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Procena sposobnosti isporuke, rizika promena i discipline izdavanja.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":456},1774882948093,[214,218,221,224,228,231,239,242,245,248,251,256,259,262,266,269,272,275,282,285,288,291,294,297,300,303,306,309,312,315,318,321,324,327,330,337,340,343,346,349,352,355,358,361,369,372,375,378,387,390,394,397,400,403,406,409,412,421,428,435,442,449],{"data":215,"type":217},{"text":216},"\u003Cb>Model-View-Controller (MVC)\u003C\u002Fb> obrazac ostaje jedan od najizdržljivijih temelja u arhitekturi veb aplikacija. Njegova dugovečnost nije slučajna. MVC opstaje jer rešava problem koji nikada zapravo ne nestaje: kako strukturirati softver tako da rast ne pretvori svaku promenu u rizik. Kada su odgovornosti dobro razdvojene, timovi mogu proširivati funkcionalnosti, revidirati interfejse, refaktorisati unutrašnjost i objavljivati promene sa daleko manje trenja.","paragraph",{"data":219,"type":217},{"text":220},"Zato ova tema prirodno pripada unutar \u003Cb>Enterprise Delivery OS\u003C\u002Fb>-a. MVC nije samo konvencija kodiranja. To je strukturna disciplina koja utiče na održivost platforme, bezbednost isporuke, napor pri migraciji, dizajn testova i operativnu jasnoću. U praktičnom inženjerskom smislu, MVC je koristan jer postavlja granice tamo gde se sistemi obično zapetljaju.",{"data":222,"type":217},{"text":223},"Unutar stajic.de strukture stubova, najjače primarno uklapanje je \u003Cb>Referentni modeli > Digitalna platforma\u003C\u002Fb>. MVC je prvenstveno tema arhitekture i granica platforme. Takođe se povezuje sa isporukom i promenama, migracijom i replatformisanjem, kontrolom izdanja i procenom isporuke, ali to su sekundarni prateći odnosi, a ne glavna klasifikacija.",{"data":225,"type":42},{"text":226,"level":227},"Šta MVC zapravo razdvaja",2,{"data":229,"type":217},{"text":230},"MVC deli aplikaciju na tri različite oblasti odgovornosti. \u003Cb>Model\u003C\u002Fb> predstavlja stanje domena, invarijante i pravila. \u003Cb>View\u003C\u002Fb> je odgovoran za prezentaciju i interakciju. \u003Cb>Controller\u003C\u002Fb> prima zahteve, koordinira relevantan slučaj korišćenja i odlučuje kako odgovor treba da bude sastavljen. Nazivi su jednostavni, ali je vrednost značajna: čisto razdvajanje smanjuje skrivenu spregnutost.",{"data":232,"type":238},{"items":233,"style":237},[234,235,236],"\u003Cb>Model\u003C\u002Fb> poseduje domensko značenje, a ne samo skladištenje podataka.","\u003Cb>View\u003C\u002Fb> jasno predstavlja informacije, a da pritom tiho ne postane poslovni sloj.","\u003Cb>Controller\u003C\u002Fb> koordinira tok, umesto da se pretvori u 'god object'.","unordered","list",{"data":240,"type":217},{"text":241},"Kada te granice oslabe, sistemi postaju teži za razumevanje. Poslovna pravila skliznu u šablone (templates). Kontroleri postaju preopterećeni orkestracijom, validacijom i sporednim efektima. Modeli postaju pasivni omotači baze podataka. Timovi tada mešaju strukturu radnog okvira sa arhitektonskom jasnoćom, iako je kodna baza već zapetljana.",{"data":243,"type":42},{"text":244,"level":227},"Zašto je MVC i dalje važan u modernim veb stekovima",{"data":246,"type":217},{"text":247},"Moderni radni okviri često govore drugačijim jezikom: komponente, composables, ostrva (islands), serverske akcije, API rute, headless isporuka i edge renderovanje. Ništa od toga ne uklanja potrebu za razdvajanjem. To samo redistribuira mesta gde se razdvajanje mora dogoditi. Ozbiljna platforma i dalje treba stabilno mesto za domenska pravila, kontrolisanu putanju za orkestraciju zahteva i prezentacioni sloj koji tajno ne poseduje polisu.",{"data":249,"type":217},{"text":250},"Zato korisno pitanje nije da li se radni okvir naziva MVC-om. Korisno pitanje je da li platforma štiti iste one granice koje je MVC dizajniran da sprovodi. Ako to ne čini, onda stek može izgledati moderno dok i dalje akumulira strukturni dug.",{"data":252,"type":255},{"text":253,"caption":254},"Novina radnog okvira ne zamenjuje arhitektonsku disciplinu. Nova sintaksa može sakriti stari haos.","Perspektiva arhitekture platforme","quote",{"data":257,"type":42},{"text":258,"level":227},"Minimalni tok zahteva",{"data":260,"type":217},{"text":261},"Najjednostavniji način da razumete MVC je da pratite zahtev kroz sistem. Korisnik zahteva stranicu ili pokreće akciju. Kontroler prima zahtev, delegira domenski rad modelima ili servisima, priprema strukturu odgovora i prosleđuje rezultat pogledu (view). Pogled renderuje izlaz. Ovaj tok je lako objasniti, ali ga mnogi sistemi krše u praksi.",{"data":263,"type":265},{"code":264},"\u002F\u002F Zahtev ulazi u sistem\nGET \u002Fproducts\u002F42 \u002F\u002F Ruter bira akciju kontrolera\nProductController.show(id = 42) \u002F\u002F Kontroler koordinira slučaj korišćenja\nproduct = ProductService.getById(42)\nviewModel = ProductPresenter.toViewModel(product) \u002F\u002F View renderuje izlaz\nreturn render(\"product\u002Fshow\", viewModel)","code",{"data":267,"type":217},{"text":268},"Ovaj primer je namerno minimalan. Vrednost nije u sintaksi. Vrednost je u vidljivosti. Recenzent može da vidi gde zahtev ulazi, gde se odvija domenski rad i gde počinje prezentacija. Ta jasnoća postaje izuzetno važna kada timovi menjaju živu platformu pod pritiskom isporuke.",{"data":270,"type":42},{"text":271,"level":227},"Šta bi Model zaista trebalo da poseduje",{"data":273,"type":217},{"text":274},"U slabim implementacijama, model postaje malo više od ORM entiteta ili zapisa u bazi podataka. To je previše usko. Koristan model štiti poslovno značenje. On treba da sadrži pravila koja moraju ostati tačna bez obzira na to da li je zahtev došao iz veb forme, admin ekrana, javnog API-ja, pozadinskog radnika ili CLI posla.",{"data":276,"type":238},{"items":277,"style":237},[278,279,280,281],"Tranzicije stanja, kao što su dozvoljene promene statusa","Invarijante koje moraju važiti kroz svaki interfejs","Validacija na nivou domena koja pripada poslovanju, a ne samo sloju forme","Izračunate vrednosti i odluke koje predstavljaju stvarno poslovno ponašanje",{"data":283,"type":265},{"code":284},"class Order: def cancel(self, actor): if self.status == \"shipped\": raise DomainError(\"Shipped orders cannot be cancelled\") if not actor.can(\"cancel_order\"): raise PermissionError(\"Actor may not cancel this order\") self.status = \"cancelled\"",{"data":286,"type":217},{"text":287},"To pravilo je malo, ali je lekcija velika. Ako je pravilo važno, potreban mu je stabilan dom. Kada takva logika postoji samo u jednoj akciji kontrolera ili jednoj UI formi, drugi put će je na kraju zaobići. Domenska pravila treba da žive tamo gde domen može zapravo da ih odbrani.",{"data":289,"type":42},{"text":290,"level":227},"Šta bi pogled (View) trebalo, a šta ne bi trebalo da radi",{"data":292,"type":217},{"text":293},"Pogled postoji da bi predstavio informacije, formatirao izlaz i podržao interakciju. Može sadržati logiku prikaza, ali ne bi trebalo da postane skriveni vlasnik važne poslovne politike. Kada šabloni počnu da odlučuju o tome kome je šta dozvoljeno, sistem postaje teži za testiranje, teži za reviziju i lakši za kvarenje.",{"data":295,"type":265},{"code":296},"\u003C!-- Dobro: logika prezentacije -->\n{% if product.stock > 0 %} \u003Cbutton>Dodaj u korpu\u003C\u002Fbutton>\n{% else %} \u003Cp>Trenutno nedostupno\u003C\u002Fp>\n{% endif %} \u003C!-- Loše: poslovna politika curi u šablon -->\n{% if user.role == \"admin\" or order.total \u003C 1000 or region == \"DE\" %} \u003Cbutton>Odobri povraćaj\u003C\u002Fbutton>\n{% endif %}",{"data":298,"type":217},{"text":299},"Pogled može odlučiti kako da prikaže stanje. Ne bi trebalo da tiho odlučuje o tome koje su politike važeće. Ta razlika izgleda mala u pregledu koda, ali vremenom postaje ogromna.",{"data":301,"type":42},{"text":302,"level":227},"Kontroleri treba da koordinišu, a ne da akumuliraju moć",{"data":304,"type":217},{"text":305},"Kontroleri su korisni jer stvaraju jasan ulaz u aplikaciju. Ali treba da ostanu fokusirani. Kontroler koji validira sirove podatke, poziva eksterne servise, izračunava domenske odluke, transformiše podatke za perzistenciju i odlučuje o konačnoj strategiji renderovanja više nije samo kontroler. On postaje skriveni sloj aplikacije zavaren za HTTP.",{"data":307,"type":265},{"code":308},"\u002F\u002F Previše odgovornosti u jednom kontroleru\nasync function checkout(req, res) { validateCart(req.body) const tax = await taxApi.calculate(req.body.address, req.body.items) const discount = computeDiscount(req.user, req.body.items) const inventory = await reserveItems(req.body.items) const payment = await chargeCard(req.body.card) const order = await db.orders.create({ tax, discount, inventory, payment }) res.render(\"checkout\u002Fsuccess\", { order })\n}",{"data":310,"type":265},{"code":311},"\u002F\u002F Bolje: kontroler delegira aplikacionim servisima\nasync function checkout(req, res) { const command = CheckoutCommand.fromHttp(req) const result = await checkoutService.execute(command) res.render(\"checkout\u002Fsuccess\", CheckoutPresenter.toViewModel(result))\n}",{"data":313,"type":217},{"text":314},"Ovde MVC postaje snažno relevantan za kvalitet isporuke. Jasne granice smanjuju obim pregleda, umanjuju uticaj promena i olakšavaju razumevanje izdanja. To je takođe razlog zašto se MVC prirodno povezuje sa \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change\">Referentnim modelom isporuke i promena\u003C\u002Fa>, koji se fokusira na bezbedno slanje promena uz eksplicitne dokaze i merljive ishode.",{"data":316,"type":42},{"text":317,"level":227},"MVC i arhitektura platforme",{"data":319,"type":217},{"text":320},"Najbolje primarno uklapanje za ovaj članak je \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Freference-models\u002Fdigital-platform\">Referentni model digitalne platforme\u003C\u002Fa>. Ta stranica opisuje strukturu nezavisnu od tehnologije za dizajniranje i upravljanje digitalnom platformom u velikom obimu. MVC se tu uklapa jer je deo strukturnog rečnika koji timovi koriste za definisanje granica, odgovornosti i površina promena unutar stvarnih sistema.",{"data":322,"type":217},{"text":323},"Platforma sa slabim unutrašnjim granicama može i dalje raditi u produkciji, ali postaje sporija za evoluciju. Nove funkcionalnosti traju duže. Bagove postaje teže lokalizovati. Refaktorisanje se odlaže. Izdanja nose više nepoznatog rizika. U tom smislu, MVC nije samo stvar stila koda. Radi se o očuvanju promenljivosti.",{"data":325,"type":42},{"text":326,"level":227},"MVC u modernim okvirima i headless sistemima",{"data":328,"type":217},{"text":329},"Ne izlaže svaki moderni stek klasični MVC direktno. U SSR okvirima, kontroleri se mogu pojaviti kao rukovaoci rutama ili serverske akcije. U API-first sistemima, prikaz (view) može živeti u zasebnom frontendu. U headless platformama, ponašanje modela može biti podeljeno na servise, domenske module i slojeve perzistencije. Ali potreba za razdvajanjem ne nestaje. Ona se jednostavno širi na više pokretnih delova.",{"data":331,"type":238},{"items":332,"style":237},[333,334,335,336],"SSR okviri često pomeraju logiku kontrolera u rukovaoce na nivou rute","API-first arhitekture postavljaju prezentaciju u poseban frontend sloj","Headless sistemi distribuiraju ponašanje modela preko granica servisa i domena","UI zasnovan na komponentama i dalje ima koristi od držanja poslovne politike van sloja prikaza",{"data":338,"type":217},{"text":339},"Dakle, dublja pouka je sledeća: MVC ostaje vredan čak i kada njegovo klasično pakovanje nestane. On opstaje kao princip dizajna jer razdvajanje odgovornosti ostaje jedna od retkih pouzdanih odbrana od entropije.",{"data":341,"type":42},{"text":342,"level":227},"Zašto MVC olakšava promenu platforme",{"data":344,"type":217},{"text":345},"Migracije nasleđenih sistema često ne uspevaju jer je stara platforma sve pomešala. Upiti se nalaze u šablonima. Prelazi stanja su sakriveni u pomoćnim datotekama. Validacija je duplirana u formama, API-jima i administratorskim alatima. Niko ne može bezbedno da pomeri jedan deo jer je previše odgovornosti spojeno. Što je razdvajanje čistije, to put migracije postaje realističniji.",{"data":347,"type":217},{"text":348},"Zato MVC ima snažnu sekundarnu važnost za \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform\">Priručnik za migraciju i promenu platforme\u003C\u002Fa>. Promena platforme nije samo vežba zamene tehnologije. To je vežba razmrsivanja. Timovi moraju da izlože i stabilizuju granice odgovornosti pre nego što prelazak postane bezbedan.",{"data":350,"type":265},{"code":351},"Redosled bezbedan za promenu platforme\n1. Izmestite domenska pravila iz šablona i kontrolera\n2. Svedite kontrolere na mapiranje zahteva i orkestraciju\n3. Uvedite prezentere ili modele pogleda za stabilne izlazne ugovore\n4. Izolujte pristup perzistenciji iza servisa ili repozitorijuma\n5. Migrirajte jednu po jednu granicu umesto da prepisujete sve odjednom",{"data":353,"type":217},{"text":354},"Ova vrsta restrukturiranja ne čini migraciju trivijalnom, ali smanjuje neizvesnost. To samo po sebi može uštedeti mesece nepotrebnog rada.",{"data":356,"type":42},{"text":357,"level":227},"Bezbednost izdanja, testiranje i operativno poverenje",{"data":359,"type":217},{"text":360},"MVC sam po sebi ne garantuje bezbedna izdanja, ali znatno olakšava postizanje bezbednosti izdanja. Tanki kontroleri, eksplicitni servisi, stabilni modeli pogleda i zaštićena domenska pravila čine jasnijim gde promena zaista utiče. To poboljšava kvalitet pregleda koda, sužava opseg grešaka i pomaže timovima da dizajniraju testove na odgovarajućem sloju.",{"data":362,"type":238},{"items":363,"style":237},[364,365,366,367,368],"Testovi modela proveravaju invarijante i poslovna pravila","Testovi servisa proveravaju ponašanje slučajeva korišćenja","Testovi kontrolera proveravaju mapiranje zahteva i tok odgovora","Testovi pogleda proveravaju očekivanja renderovanja i interakcije","End-to-end testovi štite ključne korisničke putanje bez nošenja celokupnog tereta",{"data":370,"type":217},{"text":371},"Zbog toga se MVC prirodno povezuje sa \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Frunbooks\u002Frelease-runbook\">Priručnikom za izdanja\u003C\u002Fa> i \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment\">Procenom isporuke\u003C\u002Fa>. Platformu sa eksplicitnom strukturom je lakše objaviti, lakše meriti i lakše unaprediti.",{"data":373,"type":265},{"code":374},"Obrazac promene bezbedan za objavljivanje\n1. Ažurirajte pravilo domena na jednom pouzdanom mestu\n2. Proširite testove servisa ili slučajeva korišćenja\n3. Prilagodite mapiranje kontrolera samo ako se promenio ugovor zahteva\n4. Ažurirajte prezenter ili model prikaza samo ako se promenio izlazni ugovor\n5. Verifikujte pogođene ekrane i API odgovore\n6. Objavite uz svest o povratku na prethodnu verziju i jasne dokaze",{"data":376,"type":42},{"text":377,"level":227},"Uobičajeni MVC anti-obrasci",{"data":379,"type":238},{"items":380,"style":237},[381,382,383,384,385,386],"Debeli kontroleri koji tajno sadrže sloj aplikacije","Pasivni modeli bez značajnog ponašanja domena","Prikazi koji donose skrivene odluke o polisama","Duplirana validacija na frontendu, backendu i administratorskim alatima","Nema stabilne granice prezentera ili modela prikaza između domena i korisničkog interfejsa","Konvencije radnog okvira pogrešno shvaćene kao arhitektura",{"data":388,"type":217},{"text":389},"Ovi problemi se često pojavljuju postepeno, zbog čega ih timovi potcenjuju. Baza koda može izgledati organizovano spolja, a i dalje biti strukturno slaba iznutra.",{"data":391,"type":255},{"text":392,"caption":393},"Radni okvir može generisati foldere. Ne može generisati dobre granice. Njih i dalje mora dizajnirati i braniti tim.","Perspektiva Enterprise Delivery OS-a",{"data":395,"type":42},{"text":396,"level":227},"Optimalno pozicioniranje SEO stubova",{"data":398,"type":217},{"text":399},"Unutar Enterprise Delivery OS strukture, ovaj članak pripada \u003Cb>Referentnim modelima > Digitalna platforma\u003C\u002Fb>. To je ispravno primarno pozicioniranje jer se MVC suštinski bavi strukturom platforme i granicama odgovornosti. Njegovi sekundarni prateći linkovi pripadaju \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change\">Isporuka i promena\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform\">Migracija i replatformisanje\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Frunbooks\u002Frelease-runbook\">Priručnik za izdanja\u003C\u002Fa> i \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment\">Procena isporuke\u003C\u002Fa>.",{"data":401,"type":217},{"text":402},"To pozicioniranje nije kozmetičko. Ono govori portalu, uredniku i čitaocu gde tema strukturno pripada. MVC nije prvenstveno kontrolna lista za izdanja, niti prvenstveno taktika migracije, niti prvenstveno rubrika za procenu. To je pre svega princip dizajna platforme.",{"data":404,"type":42},{"text":405,"level":227},"Završna perspektiva",{"data":407,"type":217},{"text":408},"Model-View-Controller ostaje relevantan jer softver ne postaje lakši samo zato što su radni okviri noviji. Timovima je i dalje potrebno stabilno mesto za domenska pravila, kontrolisana putanja za obradu zahteva i prezentacioni sloj koji ne uvlači poslovnu logiku u interfejs. Kada se pravilno koristi, MVC postaje više od istorijskog obrasca. On postaje praktičan instrument za čistije arhitekture, bezbednija izdanja, lakše migracije i jaču dugoročnu disciplinu isporuke.",{"data":410,"type":411},{},"delimiter",{"data":413,"type":420},{"link":414,"meta":415},"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise",{"image":416,"title":418,"description":419},{"url":417},"","Enterprise Delivery OS","Baza znanja za preduzeća o platformama, isporuci, bezbednosti i usvajanju LLM-a.","linkTool",{"data":422,"type":420},{"link":423,"meta":424},"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Freference-models\u002Fdigital-platform",{"image":425,"title":426,"description":427},{"url":417},"Referentni model digitalne platforme","Tehnološki agnostička struktura za dizajniranje i upravljanje digitalnom platformom koja podržava isporuku proizvoda u velikom obimu.",{"data":429,"type":420},{"link":430,"meta":431},"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change",{"image":432,"title":433,"description":434},{"url":417},"Referentni model isporuke i promena","Ovaj model definiše kako bezbedno isporučiti promene uz kontrolne tačke kvaliteta, jasne dokaze i merljive rezultate.",{"data":436,"type":420},{"link":437,"meta":438},"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform",{"image":439,"title":440,"description":441},{"url":417},"Priručnik za migraciju i promenu platforme","Priručnik za smanjenje rizika migracije i strukturiranje bezbednijeg rada na promeni platforme.",{"data":443,"type":420},{"link":444,"meta":445},"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Frunbooks\u002Frelease-runbook",{"image":446,"title":447,"description":448},{"url":417},"Operativni priručnik za izdanja","Operativni priručnik za provere pre objavljivanja, korake izdanja, verifikaciju i pregled nakon izdanja.",{"data":450,"type":420},{"link":451,"meta":452},"https:\u002F\u002Fstajic.de\u002Fsr\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment",{"image":453,"title":454,"description":455},{"url":417},"Procena isporuke","Procena sposobnosti isporuke, rizika promena i discipline izdavanja.","2.31","Model-View-Controller, obično skraćeno kao MVC, ostaje jedan od najtrajnijih arhitektonskih obrazaca u razvoju softvera. On timovima pruža praktičan način da razdvoje poslovnu logiku, prezentaciju i interakciju korisnika kako bi aplikacije ostale lakše za izgradnju, proširenje, testiranje i održavanje. Ovaj članak objašnjava šta je MVC, zašto je i dalje važan, gde se uklapa u današnje veb stekove i kako se povezuje sa širom arhitekturom platforme, kvalitetom isporuke, strategijom migracije i operativnom zrelošću.","\u002Fuploads\u002F2026\u002F03\u002Fmodel-view-controller-mvc-1774872805793-0bjubu.webp","model-view-controller-mvc-1774872805793-0bjubu","PUBLISHED","2023-04-12T12:57:00.000Z","2023-04-12T16:57:01.000Z","2026-03-30T15:17:26.670Z",{"en":465,"de":466,"sr":467,"es":468,"fr":469,"it":470,"ru":471,"zh":472},"\u002Fblog\u002Fmodel-view-controller-mvc","\u002Fde\u002Fblog\u002Fmodel-view-controller-mvc","\u002Fsr\u002Fblog\u002Fmodel-view-controller-mvc","\u002Fes\u002Fblog\u002Fmodel-view-controller-mvc","\u002Ffr\u002Fblog\u002Fmodel-view-controller-mvc","\u002Fit\u002Fblog\u002Fmodel-view-controller-mvc","\u002Fru\u002Fblog\u002Fmodel-view-controller-mvc","\u002Fzh\u002Fblog\u002Fmodel-view-controller-mvc",[474,477,481],{"id":475,"name":418,"slug":476},39,"enterprise",{"id":478,"name":479,"slug":480},44,"Referentni modeli","reference-models",{"id":482,"name":483,"slug":484},45,"Referentni model: Digitalna platforma","digital-platform",{"id":486,"login":487,"email":488,"displayName":489},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[491,731],{"lang":492,"title":493,"content":494,"contentJson":495,"excerpt":730},"en","Model-View-Controller (MVC): The Structural Backbone of Modern Web Applications","{\"time\":1774828800000,\"blocks\":[{\"type\":\"paragraph\",\"data\":{\"text\":\"The \u003Cb>Model-View-Controller (MVC)\u003C\u002Fb> pattern remains one of the most durable foundations in web application architecture. Its longevity is not an accident. MVC survives because it solves a problem that never really disappears: how to structure software so that growth does not turn every change into risk. When responsibility is separated well, teams can extend features, revise interfaces, refactor internals, and release changes with far less friction.\"}},{\"type\":\"paragraph\",\"data\":{\"text\":\"That is why this topic belongs naturally inside \u003Cb>Enterprise Delivery OS\u003C\u002Fb>. MVC is not just a coding convention. It is a structural discipline that influences platform maintainability, delivery safety, migration effort, test design, and operational clarity. In practical engineering terms, MVC is useful because it draws boundaries where systems usually become tangled.\"}},{\"type\":\"paragraph\",\"data\":{\"text\":\"Within the stajic.de pillar structure, the strongest primary fit is \u003Cb>Reference Models > Digital Platform\u003C\u002Fb>. MVC is first an architecture and platform-boundary topic. It also connects to delivery and change, migration and replatforming, release control, and delivery assessment, but those are secondary supporting relationships rather than the main classification.\"}},{\"type\":\"header\",\"data\":{\"text\":\"What MVC Actually Separates\",\"level\":2}},{\"type\":\"paragraph\",\"data\":{\"text\":\"MVC divides an application into three different areas of responsibility. The \u003Cb>Model\u003C\u002Fb> represents domain state, invariants, and rules. The \u003Cb>View\u003C\u002Fb> is responsible for presentation and interaction output. The \u003Cb>Controller\u003C\u002Fb> receives requests, coordinates the relevant use case, and decides how the response should be assembled. The names are simple, but the value is significant: clean separation reduces hidden coupling.\"}},{\"type\":\"list\",\"data\":{\"style\":\"unordered\",\"items\":[\"The \u003Cb>Model\u003C\u002Fb> owns domain meaning, not just storage.\",\"The \u003Cb>View\u003C\u002Fb> presents information clearly, without quietly becoming the business layer.\",\"The \u003Cb>Controller\u003C\u002Fb> coordinates flow, instead of turning into a god object.\"]}},{\"type\":\"paragraph\",\"data\":{\"text\":\"Once those boundaries weaken, systems become harder to understand. Business rules drift into templates. Controllers become overloaded with orchestration, validation, and side effects. Models become passive database wrappers. Teams then mistake framework structure for architectural clarity, even though the codebase is already entangled.\"}},{\"type\":\"header\",\"data\":{\"text\":\"Why MVC Still Matters in Modern Web Stacks\",\"level\":2}},{\"type\":\"paragraph\",\"data\":{\"text\":\"Modern frameworks often speak a different language: components, composables, islands, server actions, API routes, headless delivery, and edge rendering. None of that removes the need for separation. It only redistributes where separation must happen. A serious platform still needs a stable place for domain rules, a controlled path for request orchestration, and a presentation layer that does not secretly own policy.\"}},{\"type\":\"paragraph\",\"data\":{\"text\":\"That is why the useful question is not whether a framework calls itself MVC. The useful question is whether the platform protects the same boundaries that MVC was designed to enforce. If it does not, then the stack may look modern while still accumulating structural debt.\"}},{\"type\":\"quote\",\"data\":{\"text\":\"Framework novelty does not replace architectural discipline. New syntax can hide old chaos.\",\"caption\":\"Platform architecture perspective\"}},{\"type\":\"header\",\"data\":{\"text\":\"A Minimal Request Flow\",\"level\":2}},{\"type\":\"paragraph\",\"data\":{\"text\":\"The simplest way to understand MVC is to follow a request through the system. A user requests a page or triggers an action. The controller receives the request, delegates domain work to models or services, prepares a response structure, and passes the result to the view. The view renders the output. This flow is easy to explain, but many systems violate it in practice.\"}},{\"type\":\"code\",\"data\":{\"code\":\"\u002F\u002F Request enters the system\\nGET \u002Fproducts\u002F42 \u002F\u002F Router chooses the controller action\\nProductController.show(id = 42) \u002F\u002F Controller coordinates the use case\\nproduct = ProductService.getById(42)\\nviewModel = ProductPresenter.toViewModel(product) \u002F\u002F View renders output\\nreturn render(\\\"product\u002Fshow\\\", viewModel)\"}},{\"type\":\"paragraph\",\"data\":{\"text\":\"This example is intentionally minimal. The value is not the syntax. The value is visibility. A reviewer can see where the request enters, where domain work happens, and where presentation begins. That clarity becomes extremely important when teams are changing a live platform under delivery pressure.\"}},{\"type\":\"header\",\"data\":{\"text\":\"What the Model Should Really Own\",\"level\":2}},{\"type\":\"paragraph\",\"data\":{\"text\":\"In weak implementations, the model becomes little more than an ORM entity or database record. That is too narrow. A useful model protects business meaning. It should hold rules that must remain true regardless of whether the request came from a web form, an admin screen, a public API, a background worker, or a CLI job.\"}},{\"type\":\"list\",\"data\":{\"style\":\"unordered\",\"items\":[\"State transitions such as allowed status changes\",\"Invariants that must hold across every interface\",\"Domain-level validation that belongs to the business, not only to the form layer\",\"Calculated values and decisions that represent actual business behavior\"]}},{\"type\":\"code\",\"data\":{\"code\":\"class Order: def cancel(self, actor): if self.status == \\\"shipped\\\": raise DomainError(\\\"Shipped orders cannot be cancelled\\\") if not actor.can(\\\"cancel_order\\\"): raise PermissionError(\\\"Actor may not cancel this order\\\") self.status = \\\"cancelled\\\"\"}},{\"type\":\"paragraph\",\"data\":{\"text\":\"That rule is small, but the lesson is large. If a rule matters, it needs a stable home. When such logic exists only in one controller action or one UI form, another path will eventually bypass it. Domain rules should live where the domain can actually defend them.\"}},{\"type\":\"header\",\"data\":{\"text\":\"What the View Should and Should Not Do\",\"level\":2}},{\"type\":\"paragraph\",\"data\":{\"text\":\"The view exists to present information, format output, and support interaction. It can contain display logic, but it should not become the hidden owner of important business policy. Once templates start deciding who is allowed to do what, the system becomes harder to test, harder to audit, and easier to break.\"}},{\"type\":\"code\",\"data\":{\"code\":\"\u003C!-- Good: presentation logic -->\\n{% if product.stock > 0 %} \u003Cbutton>Add to cart\u003C\u002Fbutton>\\n{% else %} \u003Cp>Currently unavailable\u003C\u002Fp>\\n{% endif %} \u003C!-- Bad: business policy leaking into the template -->\\n{% if user.role == \\\"admin\\\" or order.total \u003C 1000 or region == \\\"DE\\\" %} \u003Cbutton>Approve refund\u003C\u002Fbutton>\\n{% endif %}\"}},{\"type\":\"paragraph\",\"data\":{\"text\":\"A view may decide how to display a state. It should not silently decide which policies are valid. That distinction looks small in code review, but it becomes huge over time.\"}},{\"type\":\"header\",\"data\":{\"text\":\"Controllers Should Coordinate, Not Accumulate Power\",\"level\":2}},{\"type\":\"paragraph\",\"data\":{\"text\":\"Controllers are useful because they create a clear entrance into the application. But they should stay focused. A controller that validates raw input, calls external services, calculates domain decisions, transforms persistence data, and decides final rendering strategy is no longer just a controller. It becomes a hidden application layer welded to HTTP.\"}},{\"type\":\"code\",\"data\":{\"code\":\"\u002F\u002F Too much responsibility in one controller\\nasync function checkout(req, res) { validateCart(req.body) const tax = await taxApi.calculate(req.body.address, req.body.items) const discount = computeDiscount(req.user, req.body.items) const inventory = await reserveItems(req.body.items) const payment = await chargeCard(req.body.card) const order = await db.orders.create({ tax, discount, inventory, payment }) res.render(\\\"checkout\u002Fsuccess\\\", { order })\\n}\"}},{\"type\":\"code\",\"data\":{\"code\":\"\u002F\u002F Better: controller delegates to application services\\nasync function checkout(req, res) { const command = CheckoutCommand.fromHttp(req) const result = await checkoutService.execute(command) res.render(\\\"checkout\u002Fsuccess\\\", CheckoutPresenter.toViewModel(result))\\n}\"}},{\"type\":\"paragraph\",\"data\":{\"text\":\"This is where MVC becomes strongly relevant to delivery quality. Clear boundaries reduce review scope, shrink change impact, and make releases easier to reason about. That is also why MVC relates naturally to the \u003Ca href=\\\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change\\\">Delivery and Change Reference Model\u003C\u002Fa>, which focuses on shipping changes safely with explicit evidence and measurable outcomes.\"}},{\"type\":\"header\",\"data\":{\"text\":\"MVC and Platform Architecture\",\"level\":2}},{\"type\":\"paragraph\",\"data\":{\"text\":\"The best primary fit for this article is the \u003Ca href=\\\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Freference-models\u002Fdigital-platform\\\">Digital Platform Reference Model\u003C\u002Fa>. That page describes a tech-agnostic structure for designing and operating a digital platform at scale. MVC fits there because it is part of the structural vocabulary teams use to define boundaries, responsibilities, and change surfaces inside real systems.\"}},{\"type\":\"paragraph\",\"data\":{\"text\":\"A platform with weak internal boundaries may still run in production, but it becomes slower to evolve. New features take longer. Bugs become harder to localize. Refactoring gets postponed. Releases carry more unknown risk. In that sense, MVC is not merely about code style. It is about preserving changeability.\"}},{\"type\":\"header\",\"data\":{\"text\":\"MVC in Modern Frameworks and Headless Systems\",\"level\":2}},{\"type\":\"paragraph\",\"data\":{\"text\":\"Not every modern stack exposes classic MVC directly. In SSR frameworks, controllers may appear as route handlers or server actions. In API-first systems, the view may live in a separate frontend. In headless platforms, model behavior may be split across services, domain modules, and persistence layers. But the need for separation does not vanish. It simply spreads across more moving parts.\"}},{\"type\":\"list\",\"data\":{\"style\":\"unordered\",\"items\":[\"SSR frameworks often move controller logic into route-level handlers\",\"API-first architectures place presentation in a distinct frontend layer\",\"Headless systems distribute model behavior across service and domain boundaries\",\"Component-based UIs still benefit from keeping business policy out of the view layer\"]}},{\"type\":\"paragraph\",\"data\":{\"text\":\"So the deeper lesson is this: MVC remains valuable even when its classical packaging disappears. It survives as a design principle because responsibility separation remains one of the few reliable defenses against entropy.\"}},{\"type\":\"header\",\"data\":{\"text\":\"Why MVC Makes Replatforming Easier\",\"level\":2}},{\"type\":\"paragraph\",\"data\":{\"text\":\"Legacy migrations often fail because the old platform mixed everything together. Queries live in templates. State transitions hide in helper files. Validation is duplicated in forms, APIs, and admin tools. Nobody can move one part safely because too many responsibilities are fused together. The cleaner the separation, the more realistic the migration path becomes.\"}},{\"type\":\"paragraph\",\"data\":{\"text\":\"That is why MVC has strong secondary relevance for the \u003Ca href=\\\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform\\\">Migration and Replatform Playbook\u003C\u002Fa>. Replatforming is not only a technology replacement exercise. It is a disentangling exercise. Teams must expose and stabilize responsibility boundaries before a move can become safe.\"}},{\"type\":\"code\",\"data\":{\"code\":\"Replatform-safe sequence\\n1. Move domain rules out of templates and controllers\\n2. Reduce controllers to request mapping and orchestration\\n3. Introduce presenters or view models for stable output contracts\\n4. Isolate persistence access behind services or repositories\\n5. Migrate one boundary at a time instead of rewriting everything at once\"}},{\"type\":\"paragraph\",\"data\":{\"text\":\"This kind of restructuring does not make migration trivial, but it reduces uncertainty. That alone can save months of waste.\"}},{\"type\":\"header\",\"data\":{\"text\":\"Release Safety, Testing, and Operational Confidence\",\"level\":2}},{\"type\":\"paragraph\",\"data\":{\"text\":\"MVC does not guarantee safe releases by itself, but it makes release safety much easier to achieve. Thin controllers, explicit services, stable view models, and protected domain rules make it clearer where a change really lands. That improves review quality, narrows the blast radius of mistakes, and helps teams design tests at the correct layer.\"}},{\"type\":\"list\",\"data\":{\"style\":\"unordered\",\"items\":[\"Model tests verify invariants and business rules\",\"Service tests verify use-case behavior\",\"Controller tests verify request mapping and response flow\",\"View tests verify rendering and interaction expectations\",\"End-to-end tests protect key user journeys without carrying the entire burden\"]}},{\"type\":\"paragraph\",\"data\":{\"text\":\"This is why MVC also connects naturally to the \u003Ca href=\\\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Frunbooks\u002Frelease-runbook\\\">Release Runbook\u003C\u002Fa> and the \u003Ca href=\\\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment\\\">Delivery Assessment\u003C\u002Fa>. A platform with explicit structure is easier to release, easier to measure, and easier to improve.\"}},{\"type\":\"code\",\"data\":{\"code\":\"Release-safe change pattern\\n1. Update the domain rule in one trusted place\\n2. Extend service or use-case tests\\n3. Adjust controller mapping only if the request contract changed\\n4. Update presenter or view model only if the output contract changed\\n5. Verify affected screens and API responses\\n6. Release with rollback awareness and clear evidence\"}},{\"type\":\"header\",\"data\":{\"text\":\"Common MVC Anti-Patterns\",\"level\":2}},{\"type\":\"list\",\"data\":{\"style\":\"unordered\",\"items\":[\"Fat controllers that secretly contain the application layer\",\"Passive models with no meaningful domain behavior\",\"Views that make hidden policy decisions\",\"Duplicated validation across frontend, backend, and admin tools\",\"No stable presenter or view-model boundary between domain and UI\",\"Framework conventions mistaken for architecture\"]}},{\"type\":\"paragraph\",\"data\":{\"text\":\"These problems often appear gradually, which is why teams underestimate them. A codebase can look organized from the outside and still be structurally weak inside.\"}},{\"type\":\"quote\",\"data\":{\"text\":\"A framework can generate folders. It cannot generate good boundaries. Those still have to be designed and defended by the team.\",\"caption\":\"Enterprise Delivery OS perspective\"}},{\"type\":\"header\",\"data\":{\"text\":\"Best-Fit SEO Pillar Placement\",\"level\":2}},{\"type\":\"paragraph\",\"data\":{\"text\":\"Inside the Enterprise Delivery OS structure, this article belongs to \u003Cb>Reference Models > Digital Platform\u003C\u002Fb>. That is the correct primary placement because MVC is fundamentally about platform structure and responsibility boundaries. Its secondary support links belong to \u003Ca href=\\\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change\\\">Delivery and Change\u003C\u002Fa>, \u003Ca href=\\\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform\\\">Migration and Replatform\u003C\u002Fa>, \u003Ca href=\\\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Frunbooks\u002Frelease-runbook\\\">Release Runbook\u003C\u002Fa>, and \u003Ca href=\\\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment\\\">Delivery Assessment\u003C\u002Fa>.\"}},{\"type\":\"paragraph\",\"data\":{\"text\":\"That placement is not cosmetic. It tells the portal, the editor, and the reader where the topic belongs structurally. MVC is not mainly a release checklist, not mainly a migration tactic, and not mainly an assessment rubric. It is first a platform design principle.\"}},{\"type\":\"header\",\"data\":{\"text\":\"Final Perspective\",\"level\":2}},{\"type\":\"paragraph\",\"data\":{\"text\":\"Model-View-Controller remains relevant because software does not become easier merely because frameworks become newer. Teams still need a stable place for domain rules, a controlled path for request handling, and a presentation layer that does not smuggle policy into the interface. Used well, MVC becomes more than a historical pattern. It becomes a practical instrument for cleaner architectures, safer releases, easier migrations, and stronger long-term delivery discipline.\"}},{\"type\":\"delimiter\",\"data\":{}},{\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fstajic.de\u002Fenterprise\",\"meta\":{\"title\":\"Enterprise Delivery OS\",\"description\":\"Enterprise knowledge base for platform, delivery, security, and LLM adoption.\",\"image\":{\"url\":\"\"}}}},{\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Freference-models\u002Fdigital-platform\",\"meta\":{\"title\":\"Digital Platform Reference Model\",\"description\":\"A tech-agnostic structure for designing and operating a digital platform that supports product delivery at scale.\",\"image\":{\"url\":\"\"}}}},{\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change\",\"meta\":{\"title\":\"Delivery and Change Reference Model\",\"description\":\"This model defines how to ship changes safely with quality gates, clear evidence, and measurable outcomes.\",\"image\":{\"url\":\"\"}}}},{\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform\",\"meta\":{\"title\":\"Migration and Replatform Playbook\",\"description\":\"Playbook for reducing migration risk and structuring safer replatforming work.\",\"image\":{\"url\":\"\"}}}},{\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Frunbooks\u002Frelease-runbook\",\"meta\":{\"title\":\"Release Runbook\",\"description\":\"Runbook for preflight checks, release steps, verification, and post-release review.\",\"image\":{\"url\":\"\"}}}},{\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment\",\"meta\":{\"title\":\"Delivery Assessment\",\"description\":\"Assessment for delivery capability, change risk, and release discipline.\",\"image\":{\"url\":\"\"}}}}],\"version\":\"2.30.8\"}",{"time":496,"blocks":497,"version":729},1774828800000,[498,501,504,507,510,513,519,522,525,528,531,535,538,541,544,547,550,553,560,562,565,568,571,574,577,580,583,586,589,592,595,598,601,604,607,614,617,620,623,626,629,632,635,638,646,649,652,655,664,667,671,674,677,680,683,686,688,694,701,708,715,722],{"data":499,"type":217},{"text":500},"The \u003Cb>Model-View-Controller (MVC)\u003C\u002Fb> pattern remains one of the most durable foundations in web application architecture. Its longevity is not an accident. MVC survives because it solves a problem that never really disappears: how to structure software so that growth does not turn every change into risk. When responsibility is separated well, teams can extend features, revise interfaces, refactor internals, and release changes with far less friction.",{"data":502,"type":217},{"text":503},"That is why this topic belongs naturally inside \u003Cb>Enterprise Delivery OS\u003C\u002Fb>. MVC is not just a coding convention. It is a structural discipline that influences platform maintainability, delivery safety, migration effort, test design, and operational clarity. In practical engineering terms, MVC is useful because it draws boundaries where systems usually become tangled.",{"data":505,"type":217},{"text":506},"Within the stajic.de pillar structure, the strongest primary fit is \u003Cb>Reference Models > Digital Platform\u003C\u002Fb>. MVC is first an architecture and platform-boundary topic. It also connects to delivery and change, migration and replatforming, release control, and delivery assessment, but those are secondary supporting relationships rather than the main classification.",{"data":508,"type":42},{"text":509,"level":227},"What MVC Actually Separates",{"data":511,"type":217},{"text":512},"MVC divides an application into three different areas of responsibility. The \u003Cb>Model\u003C\u002Fb> represents domain state, invariants, and rules. The \u003Cb>View\u003C\u002Fb> is responsible for presentation and interaction output. The \u003Cb>Controller\u003C\u002Fb> receives requests, coordinates the relevant use case, and decides how the response should be assembled. The names are simple, but the value is significant: clean separation reduces hidden coupling.",{"data":514,"type":238},{"items":515,"style":237},[516,517,518],"The \u003Cb>Model\u003C\u002Fb> owns domain meaning, not just storage.","The \u003Cb>View\u003C\u002Fb> presents information clearly, without quietly becoming the business layer.","The \u003Cb>Controller\u003C\u002Fb> coordinates flow, instead of turning into a god object.",{"data":520,"type":217},{"text":521},"Once those boundaries weaken, systems become harder to understand. Business rules drift into templates. Controllers become overloaded with orchestration, validation, and side effects. Models become passive database wrappers. Teams then mistake framework structure for architectural clarity, even though the codebase is already entangled.",{"data":523,"type":42},{"text":524,"level":227},"Why MVC Still Matters in Modern Web Stacks",{"data":526,"type":217},{"text":527},"Modern frameworks often speak a different language: components, composables, islands, server actions, API routes, headless delivery, and edge rendering. None of that removes the need for separation. It only redistributes where separation must happen. A serious platform still needs a stable place for domain rules, a controlled path for request orchestration, and a presentation layer that does not secretly own policy.",{"data":529,"type":217},{"text":530},"That is why the useful question is not whether a framework calls itself MVC. The useful question is whether the platform protects the same boundaries that MVC was designed to enforce. If it does not, then the stack may look modern while still accumulating structural debt.",{"data":532,"type":255},{"text":533,"caption":534},"Framework novelty does not replace architectural discipline. New syntax can hide old chaos.","Platform architecture perspective",{"data":536,"type":42},{"text":537,"level":227},"A Minimal Request Flow",{"data":539,"type":217},{"text":540},"The simplest way to understand MVC is to follow a request through the system. A user requests a page or triggers an action. The controller receives the request, delegates domain work to models or services, prepares a response structure, and passes the result to the view. The view renders the output. This flow is easy to explain, but many systems violate it in practice.",{"data":542,"type":265},{"code":543},"\u002F\u002F Request enters the system\nGET \u002Fproducts\u002F42 \u002F\u002F Router chooses the controller action\nProductController.show(id = 42) \u002F\u002F Controller coordinates the use case\nproduct = ProductService.getById(42)\nviewModel = ProductPresenter.toViewModel(product) \u002F\u002F View renders output\nreturn render(\"product\u002Fshow\", viewModel)",{"data":545,"type":217},{"text":546},"This example is intentionally minimal. The value is not the syntax. The value is visibility. A reviewer can see where the request enters, where domain work happens, and where presentation begins. That clarity becomes extremely important when teams are changing a live platform under delivery pressure.",{"data":548,"type":42},{"text":549,"level":227},"What the Model Should Really Own",{"data":551,"type":217},{"text":552},"In weak implementations, the model becomes little more than an ORM entity or database record. That is too narrow. A useful model protects business meaning. It should hold rules that must remain true regardless of whether the request came from a web form, an admin screen, a public API, a background worker, or a CLI job.",{"data":554,"type":238},{"items":555,"style":237},[556,557,558,559],"State transitions such as allowed status changes","Invariants that must hold across every interface","Domain-level validation that belongs to the business, not only to the form layer","Calculated values and decisions that represent actual business behavior",{"data":561,"type":265},{"code":284},{"data":563,"type":217},{"text":564},"That rule is small, but the lesson is large. If a rule matters, it needs a stable home. When such logic exists only in one controller action or one UI form, another path will eventually bypass it. Domain rules should live where the domain can actually defend them.",{"data":566,"type":42},{"text":567,"level":227},"What the View Should and Should Not Do",{"data":569,"type":217},{"text":570},"The view exists to present information, format output, and support interaction. It can contain display logic, but it should not become the hidden owner of important business policy. Once templates start deciding who is allowed to do what, the system becomes harder to test, harder to audit, and easier to break.",{"data":572,"type":265},{"code":573},"\u003C!-- Good: presentation logic -->\n{% if product.stock > 0 %} \u003Cbutton>Add to cart\u003C\u002Fbutton>\n{% else %} \u003Cp>Currently unavailable\u003C\u002Fp>\n{% endif %} \u003C!-- Bad: business policy leaking into the template -->\n{% if user.role == \"admin\" or order.total \u003C 1000 or region == \"DE\" %} \u003Cbutton>Approve refund\u003C\u002Fbutton>\n{% endif %}",{"data":575,"type":217},{"text":576},"A view may decide how to display a state. It should not silently decide which policies are valid. That distinction looks small in code review, but it becomes huge over time.",{"data":578,"type":42},{"text":579,"level":227},"Controllers Should Coordinate, Not Accumulate Power",{"data":581,"type":217},{"text":582},"Controllers are useful because they create a clear entrance into the application. But they should stay focused. A controller that validates raw input, calls external services, calculates domain decisions, transforms persistence data, and decides final rendering strategy is no longer just a controller. It becomes a hidden application layer welded to HTTP.",{"data":584,"type":265},{"code":585},"\u002F\u002F Too much responsibility in one controller\nasync function checkout(req, res) { validateCart(req.body) const tax = await taxApi.calculate(req.body.address, req.body.items) const discount = computeDiscount(req.user, req.body.items) const inventory = await reserveItems(req.body.items) const payment = await chargeCard(req.body.card) const order = await db.orders.create({ tax, discount, inventory, payment }) res.render(\"checkout\u002Fsuccess\", { order })\n}",{"data":587,"type":265},{"code":588},"\u002F\u002F Better: controller delegates to application services\nasync function checkout(req, res) { const command = CheckoutCommand.fromHttp(req) const result = await checkoutService.execute(command) res.render(\"checkout\u002Fsuccess\", CheckoutPresenter.toViewModel(result))\n}",{"data":590,"type":217},{"text":591},"This is where MVC becomes strongly relevant to delivery quality. Clear boundaries reduce review scope, shrink change impact, and make releases easier to reason about. That is also why MVC relates naturally to the \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change\">Delivery and Change Reference Model\u003C\u002Fa>, which focuses on shipping changes safely with explicit evidence and measurable outcomes.",{"data":593,"type":42},{"text":594,"level":227},"MVC and Platform Architecture",{"data":596,"type":217},{"text":597},"The best primary fit for this article is the \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Freference-models\u002Fdigital-platform\">Digital Platform Reference Model\u003C\u002Fa>. That page describes a tech-agnostic structure for designing and operating a digital platform at scale. MVC fits there because it is part of the structural vocabulary teams use to define boundaries, responsibilities, and change surfaces inside real systems.",{"data":599,"type":217},{"text":600},"A platform with weak internal boundaries may still run in production, but it becomes slower to evolve. New features take longer. Bugs become harder to localize. Refactoring gets postponed. Releases carry more unknown risk. In that sense, MVC is not merely about code style. It is about preserving changeability.",{"data":602,"type":42},{"text":603,"level":227},"MVC in Modern Frameworks and Headless Systems",{"data":605,"type":217},{"text":606},"Not every modern stack exposes classic MVC directly. In SSR frameworks, controllers may appear as route handlers or server actions. In API-first systems, the view may live in a separate frontend. In headless platforms, model behavior may be split across services, domain modules, and persistence layers. But the need for separation does not vanish. It simply spreads across more moving parts.",{"data":608,"type":238},{"items":609,"style":237},[610,611,612,613],"SSR frameworks often move controller logic into route-level handlers","API-first architectures place presentation in a distinct frontend layer","Headless systems distribute model behavior across service and domain boundaries","Component-based UIs still benefit from keeping business policy out of the view layer",{"data":615,"type":217},{"text":616},"So the deeper lesson is this: MVC remains valuable even when its classical packaging disappears. It survives as a design principle because responsibility separation remains one of the few reliable defenses against entropy.",{"data":618,"type":42},{"text":619,"level":227},"Why MVC Makes Replatforming Easier",{"data":621,"type":217},{"text":622},"Legacy migrations often fail because the old platform mixed everything together. Queries live in templates. State transitions hide in helper files. Validation is duplicated in forms, APIs, and admin tools. Nobody can move one part safely because too many responsibilities are fused together. The cleaner the separation, the more realistic the migration path becomes.",{"data":624,"type":217},{"text":625},"That is why MVC has strong secondary relevance for the \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform\">Migration and Replatform Playbook\u003C\u002Fa>. Replatforming is not only a technology replacement exercise. It is a disentangling exercise. Teams must expose and stabilize responsibility boundaries before a move can become safe.",{"data":627,"type":265},{"code":628},"Replatform-safe sequence\n1. Move domain rules out of templates and controllers\n2. Reduce controllers to request mapping and orchestration\n3. Introduce presenters or view models for stable output contracts\n4. Isolate persistence access behind services or repositories\n5. Migrate one boundary at a time instead of rewriting everything at once",{"data":630,"type":217},{"text":631},"This kind of restructuring does not make migration trivial, but it reduces uncertainty. That alone can save months of waste.",{"data":633,"type":42},{"text":634,"level":227},"Release Safety, Testing, and Operational Confidence",{"data":636,"type":217},{"text":637},"MVC does not guarantee safe releases by itself, but it makes release safety much easier to achieve. Thin controllers, explicit services, stable view models, and protected domain rules make it clearer where a change really lands. That improves review quality, narrows the blast radius of mistakes, and helps teams design tests at the correct layer.",{"data":639,"type":238},{"items":640,"style":237},[641,642,643,644,645],"Model tests verify invariants and business rules","Service tests verify use-case behavior","Controller tests verify request mapping and response flow","View tests verify rendering and interaction expectations","End-to-end tests protect key user journeys without carrying the entire burden",{"data":647,"type":217},{"text":648},"This is why MVC also connects naturally to the \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Frunbooks\u002Frelease-runbook\">Release Runbook\u003C\u002Fa> and the \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment\">Delivery Assessment\u003C\u002Fa>. A platform with explicit structure is easier to release, easier to measure, and easier to improve.",{"data":650,"type":265},{"code":651},"Release-safe change pattern\n1. Update the domain rule in one trusted place\n2. Extend service or use-case tests\n3. Adjust controller mapping only if the request contract changed\n4. Update presenter or view model only if the output contract changed\n5. Verify affected screens and API responses\n6. Release with rollback awareness and clear evidence",{"data":653,"type":42},{"text":654,"level":227},"Common MVC Anti-Patterns",{"data":656,"type":238},{"items":657,"style":237},[658,659,660,661,662,663],"Fat controllers that secretly contain the application layer","Passive models with no meaningful domain behavior","Views that make hidden policy decisions","Duplicated validation across frontend, backend, and admin tools","No stable presenter or view-model boundary between domain and UI","Framework conventions mistaken for architecture",{"data":665,"type":217},{"text":666},"These problems often appear gradually, which is why teams underestimate them. A codebase can look organized from the outside and still be structurally weak inside.",{"data":668,"type":255},{"text":669,"caption":670},"A framework can generate folders. It cannot generate good boundaries. Those still have to be designed and defended by the team.","Enterprise Delivery OS perspective",{"data":672,"type":42},{"text":673,"level":227},"Best-Fit SEO Pillar Placement",{"data":675,"type":217},{"text":676},"Inside the Enterprise Delivery OS structure, this article belongs to \u003Cb>Reference Models > Digital Platform\u003C\u002Fb>. That is the correct primary placement because MVC is fundamentally about platform structure and responsibility boundaries. Its secondary support links belong to \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change\">Delivery and Change\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform\">Migration and Replatform\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Frunbooks\u002Frelease-runbook\">Release Runbook\u003C\u002Fa>, and \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment\">Delivery Assessment\u003C\u002Fa>.",{"data":678,"type":217},{"text":679},"That placement is not cosmetic. It tells the portal, the editor, and the reader where the topic belongs structurally. MVC is not mainly a release checklist, not mainly a migration tactic, and not mainly an assessment rubric. It is first a platform design principle.",{"data":681,"type":42},{"text":682,"level":227},"Final Perspective",{"data":684,"type":217},{"text":685},"Model-View-Controller remains relevant because software does not become easier merely because frameworks become newer. Teams still need a stable place for domain rules, a controlled path for request handling, and a presentation layer that does not smuggle policy into the interface. Used well, MVC becomes more than a historical pattern. It becomes a practical instrument for cleaner architectures, safer releases, easier migrations, and stronger long-term delivery discipline.",{"data":687,"type":411},{},{"data":689,"type":420},{"link":690,"meta":691},"https:\u002F\u002Fstajic.de\u002Fenterprise",{"image":692,"title":418,"description":693},{"url":417},"Enterprise knowledge base for platform, delivery, security, and LLM adoption.",{"data":695,"type":420},{"link":696,"meta":697},"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Freference-models\u002Fdigital-platform",{"image":698,"title":699,"description":700},{"url":417},"Digital Platform Reference Model","A tech-agnostic structure for designing and operating a digital platform that supports product delivery at scale.",{"data":702,"type":420},{"link":703,"meta":704},"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change",{"image":705,"title":706,"description":707},{"url":417},"Delivery and Change Reference Model","This model defines how to ship changes safely with quality gates, clear evidence, and measurable outcomes.",{"data":709,"type":420},{"link":710,"meta":711},"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform",{"image":712,"title":713,"description":714},{"url":417},"Migration and Replatform Playbook","Playbook for reducing migration risk and structuring safer replatforming work.",{"data":716,"type":420},{"link":717,"meta":718},"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Frunbooks\u002Frelease-runbook",{"image":719,"title":720,"description":721},{"url":417},"Release Runbook","Runbook for preflight checks, release steps, verification, and post-release review.",{"data":723,"type":420},{"link":724,"meta":725},"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment",{"image":726,"title":727,"description":728},{"url":417},"Delivery Assessment","Assessment for delivery capability, change risk, and release discipline.","2.30.8","Model-View-Controller, usually shortened to MVC, remains one of the most durable architectural patterns in software development. It gives teams a practical way to separate business logic, presentation, and user interaction so applications stay easier to build, extend, test, and maintain. This article explains what MVC is, why it still matters, where it fits in today’s web stacks, and how it connects to broader platform architecture, delivery quality, migration strategy, and operational maturity.",{"lang":7,"title":208,"content":210,"contentJson":732,"excerpt":457},{"time":212,"blocks":733,"version":456},[734,736,738,740,742,744,747,749,751,753,755,757,759,761,763,765,767,769,772,774,776,778,780,782,784,786,788,790,792,794,796,798,800,802,804,807,809,811,813,815,817,819,821,823,826,828,830,832,835,837,839,841,843,845,847,849,851,855,859,863,867,871],{"data":735,"type":217},{"text":216},{"data":737,"type":217},{"text":220},{"data":739,"type":217},{"text":223},{"data":741,"type":42},{"text":226,"level":227},{"data":743,"type":217},{"text":230},{"data":745,"type":238},{"items":746,"style":237},[234,235,236],{"data":748,"type":217},{"text":241},{"data":750,"type":42},{"text":244,"level":227},{"data":752,"type":217},{"text":247},{"data":754,"type":217},{"text":250},{"data":756,"type":255},{"text":253,"caption":254},{"data":758,"type":42},{"text":258,"level":227},{"data":760,"type":217},{"text":261},{"data":762,"type":265},{"code":264},{"data":764,"type":217},{"text":268},{"data":766,"type":42},{"text":271,"level":227},{"data":768,"type":217},{"text":274},{"data":770,"type":238},{"items":771,"style":237},[278,279,280,281],{"data":773,"type":265},{"code":284},{"data":775,"type":217},{"text":287},{"data":777,"type":42},{"text":290,"level":227},{"data":779,"type":217},{"text":293},{"data":781,"type":265},{"code":296},{"data":783,"type":217},{"text":299},{"data":785,"type":42},{"text":302,"level":227},{"data":787,"type":217},{"text":305},{"data":789,"type":265},{"code":308},{"data":791,"type":265},{"code":311},{"data":793,"type":217},{"text":314},{"data":795,"type":42},{"text":317,"level":227},{"data":797,"type":217},{"text":320},{"data":799,"type":217},{"text":323},{"data":801,"type":42},{"text":326,"level":227},{"data":803,"type":217},{"text":329},{"data":805,"type":238},{"items":806,"style":237},[333,334,335,336],{"data":808,"type":217},{"text":339},{"data":810,"type":42},{"text":342,"level":227},{"data":812,"type":217},{"text":345},{"data":814,"type":217},{"text":348},{"data":816,"type":265},{"code":351},{"data":818,"type":217},{"text":354},{"data":820,"type":42},{"text":357,"level":227},{"data":822,"type":217},{"text":360},{"data":824,"type":238},{"items":825,"style":237},[364,365,366,367,368],{"data":827,"type":217},{"text":371},{"data":829,"type":265},{"code":374},{"data":831,"type":42},{"text":377,"level":227},{"data":833,"type":238},{"items":834,"style":237},[381,382,383,384,385,386],{"data":836,"type":217},{"text":389},{"data":838,"type":255},{"text":392,"caption":393},{"data":840,"type":42},{"text":396,"level":227},{"data":842,"type":217},{"text":399},{"data":844,"type":217},{"text":402},{"data":846,"type":42},{"text":405,"level":227},{"data":848,"type":217},{"text":408},{"data":850,"type":411},{},{"data":852,"type":420},{"link":414,"meta":853},{"image":854,"title":418,"description":419},{"url":417},{"data":856,"type":420},{"link":423,"meta":857},{"image":858,"title":426,"description":427},{"url":417},{"data":860,"type":420},{"link":430,"meta":861},{"image":862,"title":433,"description":434},{"url":417},{"data":864,"type":420},{"link":437,"meta":865},{"image":866,"title":440,"description":441},{"url":417},{"data":868,"type":420},{"link":444,"meta":869},{"image":870,"title":447,"description":448},{"url":417},{"data":872,"type":420},{"link":451,"meta":873},{"image":874,"title":454,"description":455},{"url":417},"Post erfolgreich abgerufen",{"items":877,"source":906,"manualIds":907,"manualMatchedIds":908},[878,885,892,899],{"id":879,"slug":880,"title":881,"excerpt":882,"featuredImage":883,"publishedAt":884},"381","enterprise-grade-multi-tenant-architecture-for-an-international-platform","Višezakupna arhitektura korporativnog nivoa za međunarodnu platformu","Loving Rocks je platforma za venčanja poslovne klase, dizajnirana sa istinskom više-zakupnom arhitekturom, izolovanim bazama podataka po zakupcu i ugrađenom internacionalizacijom za globalnu skalabilnost, bezbednost i dugoročnu operativnu stabilnost.","\u002Fuploads\u002F2026\u002F01\u002Fenterprise-grade-multi-tenant-architecture-for-an-international-platform-1769789121298-b6v7ak.webp","2026-01-30T12:04:00.000Z",{"id":886,"slug":887,"title":888,"excerpt":889,"featuredImage":890,"publishedAt":891},"459","ollama-is-not-the-product-building-production-ready-open-llm-applications","Ollama nije proizvod: Izgradnja aplikacija spremnih za produkciju sa otvorenim LLM-ovima","Pokretanje lokalnog modela pomoću Ollama-e je jednostavno. Izgradnja Open-LLM aplikacije spremne za produkciju je teža: zahteva RAG, kontrolu pristupa, apstrakciju provajdera, evaluaciju, logovanje, disciplinu puštanja u rad i kontrolisani aplikativni sloj oko modela.","\u002Fuploads\u002F2026\u002F06\u002Follama-is-not-the-product-building-production-ready-open-llm-applications-1782679361640-h0usqf.webp","2026-06-28T16:39:00.000Z",{"id":893,"slug":894,"title":895,"excerpt":896,"featuredImage":897,"publishedAt":898},"445","qwen-3-6-in-production-release-runbook-ai-rollback-and-llmops-versioning","Qwen 3.6 u produkciji: Runbook za izdavanje, AI rollback i LLMOps verziranje","Qwen 3.6 nije samo još jedna nadogradnja modela. To je istovremeno događaj objavljivanja, scenario povratka na prethodnu verziju i problem verziranja. Ovaj članak objašnjava kako Qwen 3.6 treba tretirati u produkciji kroz LLMOps disciplinu, sledljivost promptova i modela, kontrolisano uvođenje i spremnost za povratak na prethodnu verziju zasnovanu na dokazima.","\u002Fuploads\u002F2026\u002F02\u002Fnew-qwen-3-5-plus-1771515512741-dcbi9p.webp","2026-05-04T02:49:00.000Z",{"id":900,"slug":901,"title":902,"excerpt":903,"featuredImage":904,"publishedAt":905},"383","canonical-architecture-url-design-resolver-logic-api-scalability-specification","Kanonska Arhitektura, Dizajn URL-a, Logika Rezolvera, Specifikacija API-ja i Skalabilnosti","Geografski zasnovana arhitektura za otkrivanje za višekorisničke portale. Definiše kanonske URL adrese, logiku razrešavanja, strategiju keširanja i geo model za čitanje bez sprezanja sa CMS-om ili refaktorisanja baze podataka. Dizajnirano za SEO stabilnost, skalabilnost i buduća proširenja poput rezervacija i mapa.","\u002Fuploads\u002F2026\u002F01\u002Fcanonical-architecture-url-design-resolver-logic-api-scalability-specification-1769890763607-7rghbp.webp","2026-01-31T06:12:00.000Z","fallback",[],[]]