[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:fr":3,"public-menus:all":38,"post:model-view-controller-mvc:fr":205,"related:post:model-view-controller-mvc:fr:1":877},{"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","fr","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":876},{"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","Modèle-Vue-Contrôleur (MVC) : l'épine dorsale structurelle des applications web modernes","model-view-controller-mvc","\u003Cp>Le modèle \u003Cb>Modèle-Vue-Contrôleur (MVC)\u003C\u002Fb> reste l'un des fondements les plus durables de l'architecture des applications web. Sa longévité n'est pas un hasard. Le MVC survit parce qu'il résout un problème qui ne disparaît jamais vraiment : comment structurer un logiciel pour que la croissance ne transforme pas chaque changement en risque. Lorsque les responsabilités sont bien séparées, les équipes peuvent étendre les fonctionnalités, réviser les interfaces, refactoriser les composants internes et publier des modifications avec beaucoup moins de frictions.\u003C\u002Fp>\n\u003Cp>C'est pourquoi ce sujet s'inscrit naturellement dans \u003Cb>Enterprise Delivery OS\u003C\u002Fb>. Le MVC n'est pas seulement une convention de codage. C'est une discipline structurelle qui influence la maintenabilité de la plateforme, la sécurité de la livraison, l'effort de migration, la conception des tests et la clarté opérationnelle. En termes d'ingénierie pratique, le MVC est utile car il trace des limites là où les systèmes s'emmêlent habituellement.\u003C\u002Fp>\n\u003Cp>Au sein de la structure en piliers de stajic.de, l'adéquation primaire la plus forte est \u003Cb>Modèles de Référence > Plateforme Digitale\u003C\u002Fb>. Le MVC est d'abord un sujet d'architecture et de délimitation de plateforme. Il se connecte également à la livraison et au changement, à la migration et au changement de plateforme (replatforming), au contrôle des versions et à l'évaluation de la livraison, mais il s'agit de relations de soutien secondaires plutôt que de la classification principale.\u003C\u002Fp>\n\u003Ch2>Ce que le MVC sépare réellement\u003C\u002Fh2>\n\u003Cp>Le MVC divise une application en trois domaines de responsabilité différents. Le \u003Cb>Modèle\u003C\u002Fb> représente l'état du domaine, les invariants et les règles. La \u003Cb>Vue\u003C\u002Fb> est responsable de la présentation et de la sortie de l'interaction. Le \u003Cb>Contrôleur\u003C\u002Fb> reçoit les requêtes, coordonne le cas d'utilisation pertinent et décide de la manière dont la réponse doit être assemblée. Les noms sont simples, mais la valeur est significative : une séparation nette réduit le couplage caché.\u003C\u002Fp>\n\u003Cul>\u003Cli>Le \u003Cb>Modèle\u003C\u002Fb> détient la signification du domaine, pas seulement le stockage.\u003C\u002Fli>\u003Cli>La \u003Cb>Vue\u003C\u002Fb> présente les informations clairement, sans devenir discrètement la couche métier.\u003C\u002Fli>\u003Cli>Le \u003Cb>Contrôleur\u003C\u002Fb> coordonne le flux, au lieu de se transformer en objet \"dieu\" (god object).\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Une fois que ces limites s'affaiblissent, les systèmes deviennent plus difficiles à comprendre. Les règles métier dérivent vers les templates. Les contrôleurs sont surchargés par l'orchestration, la validation et les effets secondaires. Les modèles deviennent des enveloppes de base de données passives. Les équipes confondent alors la structure du framework avec la clarté architecturale, même si la base de code est déjà emmêlée.\u003C\u002Fp>\n\u003Ch2>Pourquoi le MVC compte toujours dans les piles web modernes\u003C\u002Fh2>\n\u003Cp>Les frameworks modernes parlent souvent un langage différent : composants, composables, îles (islands), actions serveur, routes API, livraison headless et rendu edge. Rien de tout cela ne supprime le besoin de séparation. Cela ne fait que redistribuer l'endroit où la séparation doit avoir lieu. Une plateforme sérieuse a toujours besoin d'un endroit stable pour les règles du domaine, d'un chemin contrôlé pour l'orchestration des requêtes et d'une couche de présentation qui ne détient pas secrètement la politique métier.\u003C\u002Fp>\n\u003Cp>C'est pourquoi la question utile n'est pas de savoir si un framework se dit MVC. La question utile est de savoir si la plateforme protège les mêmes limites que le MVC a été conçu pour imposer. Si ce n'est pas le cas, la pile peut paraître moderne tout en accumulant une dette structurelle.\u003C\u002Fp>\n\u003Cblockquote class=\"border-l-4 border-gray-300 pl-4 italic\">La nouveauté des frameworks ne remplace pas la discipline architecturale. Une nouvelle syntaxe peut cacher un vieux chaos.\u003Ccite class=\"block mt-2 text-sm\">— Perspective d'architecture de plateforme\u003C\u002Fcite>\u003C\u002Fblockquote>\n\u003Ch2>Un flux de requête minimal\u003C\u002Fh2>\n\u003Cp>La façon la plus simple de comprendre le MVC est de suivre une requête à travers le système. Un utilisateur demande une page ou déclenche une action. Le contrôleur reçoit la requête, délègue le travail du domaine aux modèles ou aux services, prépare une structure de réponse et transmet le résultat à la vue. La vue effectue le rendu de la sortie. Ce flux est facile à expliquer, mais de nombreux systèmes le violent en pratique.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>\u002F\u002F La requête entre dans le système\nGET \u002Fproducts\u002F42 \u002F\u002F Le routeur choisit l'action du contrôleur\nProductController.show(id = 42) \u002F\u002F Le contrôleur coordonne le cas d'utilisation\nproduct = ProductService.getById(42)\nviewModel = ProductPresenter.toViewModel(product) \u002F\u002F La vue effectue le rendu de la sortie\nreturn render("product\u002Fshow", viewModel)\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Cet exemple est intentionnellement minimal. La valeur n'est pas la syntaxe. La valeur est la visibilité. Un réviseur peut voir où la requête entre, où le travail du domaine se produit et où la présentation commence. Cette clarté devient extrêmement importante lorsque les équipes modifient une plateforme en production sous la pression de la livraison.\u003C\u002Fp>\n\u003Ch2>Ce que le modèle devrait réellement détenir\u003C\u002Fh2>\n\u003Cp>Dans les implémentations faibles, le modèle devient à peine plus qu'une entité ORM ou un enregistrement de base de données. C'est trop restrictif. Un modèle utile protège la signification métier. Il doit contenir des règles qui doivent rester vraies, que la requête provienne d'un formulaire web, d'un écran d'administration, d'une API publique, d'un processus d'arrière-plan ou d'une tâche CLI.\u003C\u002Fp>\n\u003Cul>\u003Cli>Transitions d'état telles que les changements de statut autorisés\u003C\u002Fli>\u003Cli>Invariants qui doivent être respectés sur chaque interface\u003C\u002Fli>\u003Cli>Validation au niveau du domaine qui appartient au métier, et pas seulement à la couche formulaire\u003C\u002Fli>\u003Cli>Valeurs calculées et décisions qui représentent le comportement réel de l'entreprise\u003C\u002Fli>\u003C\u002Ful>\n\u003Cpre class=\"code-block\">\u003Ccode>class Order: def cancel(self, actor): if self.status == "shipped": raise DomainError("Les commandes expédiées ne peuvent pas être annulées") if not actor.can("cancel_order"): raise PermissionError("L'acteur ne peut pas annuler cette commande") self.status = "cancelled"\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Cette règle est petite, mais la leçon est grande. Si une règle est importante, elle a besoin d'un foyer stable. Lorsque cette logique n'existe que dans une seule action de contrôleur ou un seul formulaire d'interface utilisateur, un autre chemin finira par la contourner. Les règles du domaine doivent résider là où le domaine peut réellement les défendre.\u003C\u002Fp>\n\u003Ch2>Ce que la Vue doit et ne doit pas faire\u003C\u002Fh2>\n\u003Cp>La vue existe pour présenter des informations, formater la sortie et soutenir l'interaction. Elle peut contenir une logique d'affichage, mais elle ne doit pas devenir le propriétaire caché d'une politique métier importante. Une fois que les templates commencent à décider qui est autorisé à faire quoi, le système devient plus difficile à tester, plus difficile à auditer et plus facile à casser.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode><!-- Bien : logique de présentation -->\n{% if product.stock > 0 %} <button>Ajouter au panier<\u002Fbutton>\n{% else %} <p>Actuellement indisponible<\u002Fp>\n{% endif %} <!-- Mauvais : fuite de la politique métier dans le template -->\n{% if user.role == "admin" or order.total < 1000 or region == "DE" %} <button>Approuver le remboursement<\u002Fbutton>\n{% endif %}\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Une vue peut décider comment afficher un état. Elle ne doit pas décider silencieusement quelles politiques sont valides. Cette distinction semble mineure lors d'une revue de code, mais elle devient énorme avec le temps.\u003C\u002Fp>\n\u003Ch2>Les contrôleurs doivent coordonner, pas accumuler le pouvoir\u003C\u002Fh2>\n\u003Cp>Les contrôleurs sont utiles car ils créent une entrée claire dans l'application. Mais ils doivent rester concentrés. Un contrôleur qui valide les entrées brutes, appelle des services externes, calcule des décisions de domaine, transforme les données de persistance et décide de la stratégie de rendu final n'est plus seulement un contrôleur. Il devient une couche d'application cachée soudée au HTTP.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>\u002F\u002F Trop de responsabilités dans un seul contrôleur\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 Mieux : le contrôleur délègue aux services d'application\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>C'est là que le MVC devient fortement pertinent pour la qualité de la livraison. Des frontières claires réduisent la portée de la revue, diminuent l'impact des changements et rendent les déploiements plus faciles à appréhender. C'est aussi pourquoi le MVC se rapporte naturellement au \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change\">Modèle de Référence pour la Livraison et le Changement\u003C\u002Fa>, qui se concentre sur l'expédition des modifications en toute sécurité avec des preuves explicites et des résultats mesurables.\u003C\u002Fp>\n\u003Ch2>MVC et architecture de plateforme\u003C\u002Fh2>\n\u003Cp>La meilleure correspondance principale pour cet article est le \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Freference-models\u002Fdigital-platform\">Modèle de Référence pour la Plateforme Numérique\u003C\u002Fa>. Cette page décrit une structure agnostique vis-à-vis de la technologie pour concevoir et exploiter une plateforme numérique à grande échelle. Le MVC y a sa place car il fait partie du vocabulaire structurel que les équipes utilisent pour définir les frontières, les responsabilités et les surfaces de changement à l'intérieur des systèmes réels.\u003C\u002Fp>\n\u003Cp>Une plateforme avec des frontières internes faibles peut toujours fonctionner en production, mais elle devient plus lente à évoluer. Les nouvelles fonctionnalités prennent plus de temps. Les bugs deviennent plus difficiles à localiser. Le refactoring est reporté. Les déploiements comportent plus de risques inconnus. En ce sens, le MVC n'est pas seulement une question de style de code. Il s'agit de préserver la capacité de changement.\u003C\u002Fp>\n\u003Ch2>Le MVC dans les frameworks modernes et les systèmes headless\u003C\u002Fh2>\n\u003Cp>Toutes les piles modernes n'exposent pas directement le MVC classique. Dans les frameworks SSR, les contrôleurs peuvent apparaître comme des gestionnaires de routes ou des actions serveur. Dans les systèmes API-first, la vue peut résider dans un frontend séparé. Dans les plateformes headless, le comportement du modèle peut être réparti entre les services, les modules de domaine et les couches de persistance. Mais le besoin de séparation ne disparaît pas. Il se répartit simplement sur davantage de pièces mobiles.\u003C\u002Fp>\n\u003Cul>\u003Cli>Les frameworks SSR déplacent souvent la logique du contrôleur vers des gestionnaires au niveau des routes\u003C\u002Fli>\u003Cli>Les architectures API-first placent la présentation dans une couche frontend distincte\u003C\u002Fli>\u003Cli>Les systèmes headless distribuent le comportement du modèle à travers les frontières des services et du domaine\u003C\u002Fli>\u003Cli>Les interfaces utilisateur basées sur des composants bénéficient toujours de l'exclusion de la politique métier de la couche de vue\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Ainsi, la leçon la plus profonde est la suivante : le MVC reste précieux même lorsque son emballage classique disparaît. Il survit en tant que principe de conception car la séparation des responsabilités reste l'une des rares défenses fiables contre l'entropie.\u003C\u002Fp>\n\u003Ch2>Pourquoi le MVC facilite le replatforming\u003C\u002Fh2>\n\u003Cp>Les migrations de systèmes hérités échouent souvent parce que l'ancienne plateforme mélangeait tout. Les requêtes vivent dans les templates. Les transitions d'état se cachent dans des fichiers d'aide. La validation est dupliquée dans les formulaires, les API et les outils d'administration. Personne ne peut déplacer une partie en toute sécurité car trop de responsabilités sont fusionnées. Plus la séparation est nette, plus le chemin de migration devient réaliste.\u003C\u002Fp>\n\u003Cp>C'est pourquoi le MVC a une forte pertinence secondaire pour le \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform\">Migration and Replatform Playbook\u003C\u002Fa>. Le replatforming n'est pas seulement un exercice de remplacement technologique. C'est un exercice de démêlage. Les équipes doivent exposer et stabiliser les limites de responsabilité avant qu'un mouvement ne puisse devenir sûr.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>Séquence sécurisée pour le replatforming\n1. Sortir les règles de domaine des templates et des contrôleurs\n2. Réduire les contrôleurs au mappage de requêtes et à l'orchestration\n3. Introduire des présentateurs ou des modèles de vue pour des contrats de sortie stables\n4. Isoler l'accès à la persistance derrière des services ou des dépôts (repositories)\n5. Migrer une limite à la fois au lieu de tout réécrire en même temps\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Ce type de restructuration ne rend pas la migration triviale, mais il réduit l'incertitude. Cela seul peut éviter des mois de gaspillage.\u003C\u002Fp>\n\u003Ch2>Sécurité des mises en production, tests et confiance opérationnelle\u003C\u002Fh2>\n\u003Cp>Le MVC ne garantit pas en soi des mises en production sûres, mais il rend la sécurité des déploiements beaucoup plus facile à atteindre. Des contrôleurs légers, des services explicites, des modèles de vue stables et des règles de domaine protégées permettent de mieux identifier l'impact réel d'un changement. Cela améliore la qualité des revues, réduit le rayon d'action des erreurs et aide les équipes à concevoir des tests au bon niveau.\u003C\u002Fp>\n\u003Cul>\u003Cli>Les tests de modèles vérifient les invariants et les règles métier\u003C\u002Fli>\u003Cli>Les tests de services vérifient le comportement des cas d'utilisation\u003C\u002Fli>\u003Cli>Les tests de contrôleurs vérifient le mappage des requêtes et le flux de réponse\u003C\u002Fli>\u003Cli>Les tests de vues vérifient le rendu et les attentes d'interaction\u003C\u002Fli>\u003Cli>Les tests de bout en bout protègent les parcours utilisateurs clés sans porter tout le fardeau\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>C'est pourquoi le MVC se connecte également naturellement au \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Frunbooks\u002Frelease-runbook\">Release Runbook\u003C\u002Fa> et à la \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment\">Delivery Assessment\u003C\u002Fa>. Une plateforme dotée d'une structure explicite est plus facile à déployer, plus facile à mesurer et plus facile à améliorer.\u003C\u002Fp>\n\u003Cpre class=\"code-block\">\u003Ccode>Modèle de changement sécurisé pour la mise en production\n1. Mettre à jour la règle de domaine dans un seul endroit de confiance\n2. Étendre les tests de service ou de cas d'utilisation\n3. Ajuster le mappage du contrôleur uniquement si le contrat de requête a changé\n4. Mettre à jour le présentateur ou le modèle de vue uniquement si le contrat de sortie a changé\n5. Vérifier les écrans affectés et les réponses de l'API\n6. Déployer avec une conscience du rollback et des preuves claires\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>Anti-patterns MVC courants\u003C\u002Fh2>\n\u003Cul>\u003Cli>Des contrôleurs obèses qui contiennent secrètement la couche application\u003C\u002Fli>\u003Cli>Des modèles passifs sans comportement de domaine significatif\u003C\u002Fli>\u003Cli>Des vues qui prennent des décisions de politique cachées\u003C\u002Fli>\u003Cli>Une validation dupliquée sur le frontend, le backend et les outils d'administration\u003C\u002Fli>\u003Cli>Aucune limite stable de présentateur ou de modèle de vue entre le domaine et l'interface utilisateur\u003C\u002Fli>\u003Cli>Des conventions de framework confondues avec l'architecture\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Ces problèmes apparaissent souvent progressivement, c'est pourquoi les équipes les sous-estiment. Une base de code peut paraître organisée de l'extérieur tout en étant structurellement faible à l'intérieur.\u003C\u002Fp>\n\u003Cblockquote class=\"border-l-4 border-gray-300 pl-4 italic\">Un framework peut générer des dossiers. Il ne peut pas générer de bonnes limites. Celles-ci doivent toujours être conçues et défendues par l'équipe.\u003Ccite class=\"block mt-2 text-sm\">— Perspective Enterprise Delivery OS\u003C\u002Fcite>\u003C\u002Fblockquote>\n\u003Ch2>Placement optimal dans les piliers SEO\u003C\u002Fh2>\n\u003Cp>Au sein de la structure Enterprise Delivery OS, cet article appartient à \u003Cb>Reference Models > Digital Platform\u003C\u002Fb>. C'est le placement primaire correct car le MVC concerne fondamentalement la structure de la plateforme et les limites de responsabilité. Ses liens de support secondaires appartiennent à \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change\">Delivery and Change\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform\">Migration and Replatform\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Frunbooks\u002Frelease-runbook\">Release Runbook\u003C\u002Fa> et \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment\">Delivery Assessment\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>Ce placement n'est pas cosmétique. Il indique au portail, à l'éditeur et au lecteur où le sujet se situe structurellement. Le MVC n'est pas principalement une liste de contrôle de mise en production, ni principalement une tactique de migration, ni principalement une rubrique d'évaluation. C'est d'abord un principe de conception de plateforme.\u003C\u002Fp>\n\u003Ch2>Perspective finale\u003C\u002Fh2>\n\u003Cp>Le modèle Modèle-Vue-Contrôleur reste pertinent car le développement logiciel ne devient pas plus simple du seul fait de la nouveauté des frameworks. Les équipes ont toujours besoin d'un socle stable pour les règles métier, d'un parcours contrôlé pour le traitement des requêtes et d'une couche de présentation qui n'intègre pas de logique de gestion dans l'interface. Bien utilisé, le MVC devient plus qu'un simple modèle historique. Il devient un instrument pratique pour des architectures plus saines, des déploiements plus sûrs, des migrations facilitées et une discipline de livraison plus rigoureuse sur le long terme.\u003C\u002Fp>\n\u003Cdiv class=\"ce-delimiter cdx-block my-8\">\u003C\u002Fdiv>\n\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\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\">Base de connaissances d'entreprise pour la plateforme, la livraison, la sécurité et l'adoption des LLM.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\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\">Modèle de référence de plateforme numérique\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Une structure agnostique sur le plan technologique pour concevoir et exploiter une plateforme numérique soutenant la livraison de produits à l'échelle.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\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\">Modèle de référence pour la livraison et le changement\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Ce modèle définit comment déployer des changements en toute sécurité avec des jalons de qualité, des preuves tangibles et des résultats mesurables.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\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\">Guide stratégique de migration et de changement de plateforme\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Guide stratégique pour réduire les risques de migration et structurer les travaux de changement de plateforme en toute sécurité.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\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\">Guide opérationnel de mise en production\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Guide opérationnel pour les vérifications préliminaires, les étapes de mise en production, la validation et la revue post-déploiement.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\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\">Évaluation de la livraison\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Évaluation de la capacité de livraison, des risques de changement et de la discipline de mise en production.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":456},1774883248035,[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},"Le modèle \u003Cb>Modèle-Vue-Contrôleur (MVC)\u003C\u002Fb> reste l'un des fondements les plus durables de l'architecture des applications web. Sa longévité n'est pas un hasard. Le MVC survit parce qu'il résout un problème qui ne disparaît jamais vraiment : comment structurer un logiciel pour que la croissance ne transforme pas chaque changement en risque. Lorsque les responsabilités sont bien séparées, les équipes peuvent étendre les fonctionnalités, réviser les interfaces, refactoriser les composants internes et publier des modifications avec beaucoup moins de frictions.","paragraph",{"data":219,"type":217},{"text":220},"C'est pourquoi ce sujet s'inscrit naturellement dans \u003Cb>Enterprise Delivery OS\u003C\u002Fb>. Le MVC n'est pas seulement une convention de codage. C'est une discipline structurelle qui influence la maintenabilité de la plateforme, la sécurité de la livraison, l'effort de migration, la conception des tests et la clarté opérationnelle. En termes d'ingénierie pratique, le MVC est utile car il trace des limites là où les systèmes s'emmêlent habituellement.",{"data":222,"type":217},{"text":223},"Au sein de la structure en piliers de stajic.de, l'adéquation primaire la plus forte est \u003Cb>Modèles de Référence > Plateforme Digitale\u003C\u002Fb>. Le MVC est d'abord un sujet d'architecture et de délimitation de plateforme. Il se connecte également à la livraison et au changement, à la migration et au changement de plateforme (replatforming), au contrôle des versions et à l'évaluation de la livraison, mais il s'agit de relations de soutien secondaires plutôt que de la classification principale.",{"data":225,"type":42},{"text":226,"level":227},"Ce que le MVC sépare réellement",2,{"data":229,"type":217},{"text":230},"Le MVC divise une application en trois domaines de responsabilité différents. Le \u003Cb>Modèle\u003C\u002Fb> représente l'état du domaine, les invariants et les règles. La \u003Cb>Vue\u003C\u002Fb> est responsable de la présentation et de la sortie de l'interaction. Le \u003Cb>Contrôleur\u003C\u002Fb> reçoit les requêtes, coordonne le cas d'utilisation pertinent et décide de la manière dont la réponse doit être assemblée. Les noms sont simples, mais la valeur est significative : une séparation nette réduit le couplage caché.",{"data":232,"type":238},{"items":233,"style":237},[234,235,236],"Le \u003Cb>Modèle\u003C\u002Fb> détient la signification du domaine, pas seulement le stockage.","La \u003Cb>Vue\u003C\u002Fb> présente les informations clairement, sans devenir discrètement la couche métier.","Le \u003Cb>Contrôleur\u003C\u002Fb> coordonne le flux, au lieu de se transformer en objet \"dieu\" (god object).","unordered","list",{"data":240,"type":217},{"text":241},"Une fois que ces limites s'affaiblissent, les systèmes deviennent plus difficiles à comprendre. Les règles métier dérivent vers les templates. Les contrôleurs sont surchargés par l'orchestration, la validation et les effets secondaires. Les modèles deviennent des enveloppes de base de données passives. Les équipes confondent alors la structure du framework avec la clarté architecturale, même si la base de code est déjà emmêlée.",{"data":243,"type":42},{"text":244,"level":227},"Pourquoi le MVC compte toujours dans les piles web modernes",{"data":246,"type":217},{"text":247},"Les frameworks modernes parlent souvent un langage différent : composants, composables, îles (islands), actions serveur, routes API, livraison headless et rendu edge. Rien de tout cela ne supprime le besoin de séparation. Cela ne fait que redistribuer l'endroit où la séparation doit avoir lieu. Une plateforme sérieuse a toujours besoin d'un endroit stable pour les règles du domaine, d'un chemin contrôlé pour l'orchestration des requêtes et d'une couche de présentation qui ne détient pas secrètement la politique métier.",{"data":249,"type":217},{"text":250},"C'est pourquoi la question utile n'est pas de savoir si un framework se dit MVC. La question utile est de savoir si la plateforme protège les mêmes limites que le MVC a été conçu pour imposer. Si ce n'est pas le cas, la pile peut paraître moderne tout en accumulant une dette structurelle.",{"data":252,"type":255},{"text":253,"caption":254},"La nouveauté des frameworks ne remplace pas la discipline architecturale. Une nouvelle syntaxe peut cacher un vieux chaos.","Perspective d'architecture de plateforme","quote",{"data":257,"type":42},{"text":258,"level":227},"Un flux de requête minimal",{"data":260,"type":217},{"text":261},"La façon la plus simple de comprendre le MVC est de suivre une requête à travers le système. Un utilisateur demande une page ou déclenche une action. Le contrôleur reçoit la requête, délègue le travail du domaine aux modèles ou aux services, prépare une structure de réponse et transmet le résultat à la vue. La vue effectue le rendu de la sortie. Ce flux est facile à expliquer, mais de nombreux systèmes le violent en pratique.",{"data":263,"type":265},{"code":264},"\u002F\u002F La requête entre dans le système\nGET \u002Fproducts\u002F42 \u002F\u002F Le routeur choisit l'action du contrôleur\nProductController.show(id = 42) \u002F\u002F Le contrôleur coordonne le cas d'utilisation\nproduct = ProductService.getById(42)\nviewModel = ProductPresenter.toViewModel(product) \u002F\u002F La vue effectue le rendu de la sortie\nreturn render(\"product\u002Fshow\", viewModel)","code",{"data":267,"type":217},{"text":268},"Cet exemple est intentionnellement minimal. La valeur n'est pas la syntaxe. La valeur est la visibilité. Un réviseur peut voir où la requête entre, où le travail du domaine se produit et où la présentation commence. Cette clarté devient extrêmement importante lorsque les équipes modifient une plateforme en production sous la pression de la livraison.",{"data":270,"type":42},{"text":271,"level":227},"Ce que le modèle devrait réellement détenir",{"data":273,"type":217},{"text":274},"Dans les implémentations faibles, le modèle devient à peine plus qu'une entité ORM ou un enregistrement de base de données. C'est trop restrictif. Un modèle utile protège la signification métier. Il doit contenir des règles qui doivent rester vraies, que la requête provienne d'un formulaire web, d'un écran d'administration, d'une API publique, d'un processus d'arrière-plan ou d'une tâche CLI.",{"data":276,"type":238},{"items":277,"style":237},[278,279,280,281],"Transitions d'état telles que les changements de statut autorisés","Invariants qui doivent être respectés sur chaque interface","Validation au niveau du domaine qui appartient au métier, et pas seulement à la couche formulaire","Valeurs calculées et décisions qui représentent le comportement réel de l'entreprise",{"data":283,"type":265},{"code":284},"class Order: def cancel(self, actor): if self.status == \"shipped\": raise DomainError(\"Les commandes expédiées ne peuvent pas être annulées\") if not actor.can(\"cancel_order\"): raise PermissionError(\"L'acteur ne peut pas annuler cette commande\") self.status = \"cancelled\"",{"data":286,"type":217},{"text":287},"Cette règle est petite, mais la leçon est grande. Si une règle est importante, elle a besoin d'un foyer stable. Lorsque cette logique n'existe que dans une seule action de contrôleur ou un seul formulaire d'interface utilisateur, un autre chemin finira par la contourner. Les règles du domaine doivent résider là où le domaine peut réellement les défendre.",{"data":289,"type":42},{"text":290,"level":227},"Ce que la Vue doit et ne doit pas faire",{"data":292,"type":217},{"text":293},"La vue existe pour présenter des informations, formater la sortie et soutenir l'interaction. Elle peut contenir une logique d'affichage, mais elle ne doit pas devenir le propriétaire caché d'une politique métier importante. Une fois que les templates commencent à décider qui est autorisé à faire quoi, le système devient plus difficile à tester, plus difficile à auditer et plus facile à casser.",{"data":295,"type":265},{"code":296},"\u003C!-- Bien : logique de présentation -->\n{% if product.stock > 0 %} \u003Cbutton>Ajouter au panier\u003C\u002Fbutton>\n{% else %} \u003Cp>Actuellement indisponible\u003C\u002Fp>\n{% endif %} \u003C!-- Mauvais : fuite de la politique métier dans le template -->\n{% if user.role == \"admin\" or order.total \u003C 1000 or region == \"DE\" %} \u003Cbutton>Approuver le remboursement\u003C\u002Fbutton>\n{% endif %}",{"data":298,"type":217},{"text":299},"Une vue peut décider comment afficher un état. Elle ne doit pas décider silencieusement quelles politiques sont valides. Cette distinction semble mineure lors d'une revue de code, mais elle devient énorme avec le temps.",{"data":301,"type":42},{"text":302,"level":227},"Les contrôleurs doivent coordonner, pas accumuler le pouvoir",{"data":304,"type":217},{"text":305},"Les contrôleurs sont utiles car ils créent une entrée claire dans l'application. Mais ils doivent rester concentrés. Un contrôleur qui valide les entrées brutes, appelle des services externes, calcule des décisions de domaine, transforme les données de persistance et décide de la stratégie de rendu final n'est plus seulement un contrôleur. Il devient une couche d'application cachée soudée au HTTP.",{"data":307,"type":265},{"code":308},"\u002F\u002F Trop de responsabilités dans un seul contrôleur\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 Mieux : le contrôleur délègue aux services d'application\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},"C'est là que le MVC devient fortement pertinent pour la qualité de la livraison. Des frontières claires réduisent la portée de la revue, diminuent l'impact des changements et rendent les déploiements plus faciles à appréhender. C'est aussi pourquoi le MVC se rapporte naturellement au \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change\">Modèle de Référence pour la Livraison et le Changement\u003C\u002Fa>, qui se concentre sur l'expédition des modifications en toute sécurité avec des preuves explicites et des résultats mesurables.",{"data":316,"type":42},{"text":317,"level":227},"MVC et architecture de plateforme",{"data":319,"type":217},{"text":320},"La meilleure correspondance principale pour cet article est le \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Freference-models\u002Fdigital-platform\">Modèle de Référence pour la Plateforme Numérique\u003C\u002Fa>. Cette page décrit une structure agnostique vis-à-vis de la technologie pour concevoir et exploiter une plateforme numérique à grande échelle. Le MVC y a sa place car il fait partie du vocabulaire structurel que les équipes utilisent pour définir les frontières, les responsabilités et les surfaces de changement à l'intérieur des systèmes réels.",{"data":322,"type":217},{"text":323},"Une plateforme avec des frontières internes faibles peut toujours fonctionner en production, mais elle devient plus lente à évoluer. Les nouvelles fonctionnalités prennent plus de temps. Les bugs deviennent plus difficiles à localiser. Le refactoring est reporté. Les déploiements comportent plus de risques inconnus. En ce sens, le MVC n'est pas seulement une question de style de code. Il s'agit de préserver la capacité de changement.",{"data":325,"type":42},{"text":326,"level":227},"Le MVC dans les frameworks modernes et les systèmes headless",{"data":328,"type":217},{"text":329},"Toutes les piles modernes n'exposent pas directement le MVC classique. Dans les frameworks SSR, les contrôleurs peuvent apparaître comme des gestionnaires de routes ou des actions serveur. Dans les systèmes API-first, la vue peut résider dans un frontend séparé. Dans les plateformes headless, le comportement du modèle peut être réparti entre les services, les modules de domaine et les couches de persistance. Mais le besoin de séparation ne disparaît pas. Il se répartit simplement sur davantage de pièces mobiles.",{"data":331,"type":238},{"items":332,"style":237},[333,334,335,336],"Les frameworks SSR déplacent souvent la logique du contrôleur vers des gestionnaires au niveau des routes","Les architectures API-first placent la présentation dans une couche frontend distincte","Les systèmes headless distribuent le comportement du modèle à travers les frontières des services et du domaine","Les interfaces utilisateur basées sur des composants bénéficient toujours de l'exclusion de la politique métier de la couche de vue",{"data":338,"type":217},{"text":339},"Ainsi, la leçon la plus profonde est la suivante : le MVC reste précieux même lorsque son emballage classique disparaît. Il survit en tant que principe de conception car la séparation des responsabilités reste l'une des rares défenses fiables contre l'entropie.",{"data":341,"type":42},{"text":342,"level":227},"Pourquoi le MVC facilite le replatforming",{"data":344,"type":217},{"text":345},"Les migrations de systèmes hérités échouent souvent parce que l'ancienne plateforme mélangeait tout. Les requêtes vivent dans les templates. Les transitions d'état se cachent dans des fichiers d'aide. La validation est dupliquée dans les formulaires, les API et les outils d'administration. Personne ne peut déplacer une partie en toute sécurité car trop de responsabilités sont fusionnées. Plus la séparation est nette, plus le chemin de migration devient réaliste.",{"data":347,"type":217},{"text":348},"C'est pourquoi le MVC a une forte pertinence secondaire pour le \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform\">Migration and Replatform Playbook\u003C\u002Fa>. Le replatforming n'est pas seulement un exercice de remplacement technologique. C'est un exercice de démêlage. Les équipes doivent exposer et stabiliser les limites de responsabilité avant qu'un mouvement ne puisse devenir sûr.",{"data":350,"type":265},{"code":351},"Séquence sécurisée pour le replatforming\n1. Sortir les règles de domaine des templates et des contrôleurs\n2. Réduire les contrôleurs au mappage de requêtes et à l'orchestration\n3. Introduire des présentateurs ou des modèles de vue pour des contrats de sortie stables\n4. Isoler l'accès à la persistance derrière des services ou des dépôts (repositories)\n5. Migrer une limite à la fois au lieu de tout réécrire en même temps",{"data":353,"type":217},{"text":354},"Ce type de restructuration ne rend pas la migration triviale, mais il réduit l'incertitude. Cela seul peut éviter des mois de gaspillage.",{"data":356,"type":42},{"text":357,"level":227},"Sécurité des mises en production, tests et confiance opérationnelle",{"data":359,"type":217},{"text":360},"Le MVC ne garantit pas en soi des mises en production sûres, mais il rend la sécurité des déploiements beaucoup plus facile à atteindre. Des contrôleurs légers, des services explicites, des modèles de vue stables et des règles de domaine protégées permettent de mieux identifier l'impact réel d'un changement. Cela améliore la qualité des revues, réduit le rayon d'action des erreurs et aide les équipes à concevoir des tests au bon niveau.",{"data":362,"type":238},{"items":363,"style":237},[364,365,366,367,368],"Les tests de modèles vérifient les invariants et les règles métier","Les tests de services vérifient le comportement des cas d'utilisation","Les tests de contrôleurs vérifient le mappage des requêtes et le flux de réponse","Les tests de vues vérifient le rendu et les attentes d'interaction","Les tests de bout en bout protègent les parcours utilisateurs clés sans porter tout le fardeau",{"data":370,"type":217},{"text":371},"C'est pourquoi le MVC se connecte également naturellement au \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Frunbooks\u002Frelease-runbook\">Release Runbook\u003C\u002Fa> et à la \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment\">Delivery Assessment\u003C\u002Fa>. Une plateforme dotée d'une structure explicite est plus facile à déployer, plus facile à mesurer et plus facile à améliorer.",{"data":373,"type":265},{"code":374},"Modèle de changement sécurisé pour la mise en production\n1. Mettre à jour la règle de domaine dans un seul endroit de confiance\n2. Étendre les tests de service ou de cas d'utilisation\n3. Ajuster le mappage du contrôleur uniquement si le contrat de requête a changé\n4. Mettre à jour le présentateur ou le modèle de vue uniquement si le contrat de sortie a changé\n5. Vérifier les écrans affectés et les réponses de l'API\n6. Déployer avec une conscience du rollback et des preuves claires",{"data":376,"type":42},{"text":377,"level":227},"Anti-patterns MVC courants",{"data":379,"type":238},{"items":380,"style":237},[381,382,383,384,385,386],"Des contrôleurs obèses qui contiennent secrètement la couche application","Des modèles passifs sans comportement de domaine significatif","Des vues qui prennent des décisions de politique cachées","Une validation dupliquée sur le frontend, le backend et les outils d'administration","Aucune limite stable de présentateur ou de modèle de vue entre le domaine et l'interface utilisateur","Des conventions de framework confondues avec l'architecture",{"data":388,"type":217},{"text":389},"Ces problèmes apparaissent souvent progressivement, c'est pourquoi les équipes les sous-estiment. Une base de code peut paraître organisée de l'extérieur tout en étant structurellement faible à l'intérieur.",{"data":391,"type":255},{"text":392,"caption":393},"Un framework peut générer des dossiers. Il ne peut pas générer de bonnes limites. Celles-ci doivent toujours être conçues et défendues par l'équipe.","Perspective Enterprise Delivery OS",{"data":395,"type":42},{"text":396,"level":227},"Placement optimal dans les piliers SEO",{"data":398,"type":217},{"text":399},"Au sein de la structure Enterprise Delivery OS, cet article appartient à \u003Cb>Reference Models > Digital Platform\u003C\u002Fb>. C'est le placement primaire correct car le MVC concerne fondamentalement la structure de la plateforme et les limites de responsabilité. Ses liens de support secondaires appartiennent à \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change\">Delivery and Change\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform\">Migration and Replatform\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Frunbooks\u002Frelease-runbook\">Release Runbook\u003C\u002Fa> et \u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment\">Delivery Assessment\u003C\u002Fa>.",{"data":401,"type":217},{"text":402},"Ce placement n'est pas cosmétique. Il indique au portail, à l'éditeur et au lecteur où le sujet se situe structurellement. Le MVC n'est pas principalement une liste de contrôle de mise en production, ni principalement une tactique de migration, ni principalement une rubrique d'évaluation. C'est d'abord un principe de conception de plateforme.",{"data":404,"type":42},{"text":405,"level":227},"Perspective finale",{"data":407,"type":217},{"text":408},"Le modèle Modèle-Vue-Contrôleur reste pertinent car le développement logiciel ne devient pas plus simple du seul fait de la nouveauté des frameworks. Les équipes ont toujours besoin d'un socle stable pour les règles métier, d'un parcours contrôlé pour le traitement des requêtes et d'une couche de présentation qui n'intègre pas de logique de gestion dans l'interface. Bien utilisé, le MVC devient plus qu'un simple modèle historique. Il devient un instrument pratique pour des architectures plus saines, des déploiements plus sûrs, des migrations facilitées et une discipline de livraison plus rigoureuse sur le long terme.",{"data":410,"type":411},{},"delimiter",{"data":413,"type":420},{"link":414,"meta":415},"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise",{"image":416,"title":418,"description":419},{"url":417},"","Enterprise Delivery OS","Base de connaissances d'entreprise pour la plateforme, la livraison, la sécurité et l'adoption des LLM.","linkTool",{"data":422,"type":420},{"link":423,"meta":424},"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Freference-models\u002Fdigital-platform",{"image":425,"title":426,"description":427},{"url":417},"Modèle de référence de plateforme numérique","Une structure agnostique sur le plan technologique pour concevoir et exploiter une plateforme numérique soutenant la livraison de produits à l'échelle.",{"data":429,"type":420},{"link":430,"meta":431},"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change",{"image":432,"title":433,"description":434},{"url":417},"Modèle de référence pour la livraison et le changement","Ce modèle définit comment déployer des changements en toute sécurité avec des jalons de qualité, des preuves tangibles et des résultats mesurables.",{"data":436,"type":420},{"link":437,"meta":438},"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform",{"image":439,"title":440,"description":441},{"url":417},"Guide stratégique de migration et de changement de plateforme","Guide stratégique pour réduire les risques de migration et structurer les travaux de changement de plateforme en toute sécurité.",{"data":443,"type":420},{"link":444,"meta":445},"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Frunbooks\u002Frelease-runbook",{"image":446,"title":447,"description":448},{"url":417},"Guide opérationnel de mise en production","Guide opérationnel pour les vérifications préliminaires, les étapes de mise en production, la validation et la revue post-déploiement.",{"data":450,"type":420},{"link":451,"meta":452},"https:\u002F\u002Fstajic.de\u002Ffr\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment",{"image":453,"title":454,"description":455},{"url":417},"Évaluation de la livraison","Évaluation de la capacité de livraison, des risques de changement et de la discipline de mise en production.","2.31","Modèle-Vue-Contrôleur, généralement abrégé en MVC, reste l'un des modèles d'architecture les plus durables dans le développement de logiciels. Il offre aux équipes un moyen pratique de séparer la logique métier, la présentation et l'interaction utilisateur afin que les applications restent plus faciles à construire, à étendre, à tester et à maintenir. Cet article explique ce qu'est le MVC, pourquoi il est toujours important, où il s'intègre dans les piles Web d'aujourd'hui et comment il se connecte à l'architecture de plateforme plus large, à la qualité de la livraison, à la stratégie de migration et à la maturité opérationnelle.","\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,"Modèles de référence","reference-models",{"id":482,"name":483,"slug":484},45,"Modèle de référence : Plateforme numérique","digital-platform",{"id":486,"login":487,"email":488,"displayName":489},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[491,732],{"lang":492,"title":493,"content":494,"contentJson":495,"excerpt":731},"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":730},1774828800000,[498,501,504,507,510,513,519,522,525,528,531,535,538,541,544,547,550,553,560,563,566,569,572,575,578,581,584,587,590,593,596,599,602,605,608,615,618,621,624,627,630,633,636,639,647,650,653,656,665,668,672,675,678,681,684,687,689,695,702,709,716,723],{"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":562},"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":564,"type":217},{"text":565},"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":567,"type":42},{"text":568,"level":227},"What the View Should and Should Not Do",{"data":570,"type":217},{"text":571},"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":573,"type":265},{"code":574},"\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":576,"type":217},{"text":577},"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":579,"type":42},{"text":580,"level":227},"Controllers Should Coordinate, Not Accumulate Power",{"data":582,"type":217},{"text":583},"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":585,"type":265},{"code":586},"\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":588,"type":265},{"code":589},"\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":591,"type":217},{"text":592},"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":594,"type":42},{"text":595,"level":227},"MVC and Platform Architecture",{"data":597,"type":217},{"text":598},"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":600,"type":217},{"text":601},"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":603,"type":42},{"text":604,"level":227},"MVC in Modern Frameworks and Headless Systems",{"data":606,"type":217},{"text":607},"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":609,"type":238},{"items":610,"style":237},[611,612,613,614],"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":616,"type":217},{"text":617},"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":619,"type":42},{"text":620,"level":227},"Why MVC Makes Replatforming Easier",{"data":622,"type":217},{"text":623},"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":625,"type":217},{"text":626},"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":628,"type":265},{"code":629},"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":631,"type":217},{"text":632},"This kind of restructuring does not make migration trivial, but it reduces uncertainty. That alone can save months of waste.",{"data":634,"type":42},{"text":635,"level":227},"Release Safety, Testing, and Operational Confidence",{"data":637,"type":217},{"text":638},"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":640,"type":238},{"items":641,"style":237},[642,643,644,645,646],"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":648,"type":217},{"text":649},"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":651,"type":265},{"code":652},"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":654,"type":42},{"text":655,"level":227},"Common MVC Anti-Patterns",{"data":657,"type":238},{"items":658,"style":237},[659,660,661,662,663,664],"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":666,"type":217},{"text":667},"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":669,"type":255},{"text":670,"caption":671},"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":673,"type":42},{"text":674,"level":227},"Best-Fit SEO Pillar Placement",{"data":676,"type":217},{"text":677},"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":679,"type":217},{"text":680},"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":682,"type":42},{"text":683,"level":227},"Final Perspective",{"data":685,"type":217},{"text":686},"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":688,"type":411},{},{"data":690,"type":420},{"link":691,"meta":692},"https:\u002F\u002Fstajic.de\u002Fenterprise",{"image":693,"title":418,"description":694},{"url":417},"Enterprise knowledge base for platform, delivery, security, and LLM adoption.",{"data":696,"type":420},{"link":697,"meta":698},"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Freference-models\u002Fdigital-platform",{"image":699,"title":700,"description":701},{"url":417},"Digital Platform Reference Model","A tech-agnostic structure for designing and operating a digital platform that supports product delivery at scale.",{"data":703,"type":420},{"link":704,"meta":705},"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Freference-models\u002Fdelivery-and-change",{"image":706,"title":707,"description":708},{"url":417},"Delivery and Change Reference Model","This model defines how to ship changes safely with quality gates, clear evidence, and measurable outcomes.",{"data":710,"type":420},{"link":711,"meta":712},"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Fplaybooks\u002Fmigration-and-replatform",{"image":713,"title":714,"description":715},{"url":417},"Migration and Replatform Playbook","Playbook for reducing migration risk and structuring safer replatforming work.",{"data":717,"type":420},{"link":718,"meta":719},"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Frunbooks\u002Frelease-runbook",{"image":720,"title":721,"description":722},{"url":417},"Release Runbook","Runbook for preflight checks, release steps, verification, and post-release review.",{"data":724,"type":420},{"link":725,"meta":726},"https:\u002F\u002Fstajic.de\u002Fenterprise\u002Fassessments\u002Fdelivery-assessment",{"image":727,"title":728,"description":729},{"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":733,"excerpt":457},{"time":212,"blocks":734,"version":456},[735,737,739,741,743,745,748,750,752,754,756,758,760,762,764,766,768,770,773,775,777,779,781,783,785,787,789,791,793,795,797,799,801,803,805,808,810,812,814,816,818,820,822,824,827,829,831,833,836,838,840,842,844,846,848,850,852,856,860,864,868,872],{"data":736,"type":217},{"text":216},{"data":738,"type":217},{"text":220},{"data":740,"type":217},{"text":223},{"data":742,"type":42},{"text":226,"level":227},{"data":744,"type":217},{"text":230},{"data":746,"type":238},{"items":747,"style":237},[234,235,236],{"data":749,"type":217},{"text":241},{"data":751,"type":42},{"text":244,"level":227},{"data":753,"type":217},{"text":247},{"data":755,"type":217},{"text":250},{"data":757,"type":255},{"text":253,"caption":254},{"data":759,"type":42},{"text":258,"level":227},{"data":761,"type":217},{"text":261},{"data":763,"type":265},{"code":264},{"data":765,"type":217},{"text":268},{"data":767,"type":42},{"text":271,"level":227},{"data":769,"type":217},{"text":274},{"data":771,"type":238},{"items":772,"style":237},[278,279,280,281],{"data":774,"type":265},{"code":284},{"data":776,"type":217},{"text":287},{"data":778,"type":42},{"text":290,"level":227},{"data":780,"type":217},{"text":293},{"data":782,"type":265},{"code":296},{"data":784,"type":217},{"text":299},{"data":786,"type":42},{"text":302,"level":227},{"data":788,"type":217},{"text":305},{"data":790,"type":265},{"code":308},{"data":792,"type":265},{"code":311},{"data":794,"type":217},{"text":314},{"data":796,"type":42},{"text":317,"level":227},{"data":798,"type":217},{"text":320},{"data":800,"type":217},{"text":323},{"data":802,"type":42},{"text":326,"level":227},{"data":804,"type":217},{"text":329},{"data":806,"type":238},{"items":807,"style":237},[333,334,335,336],{"data":809,"type":217},{"text":339},{"data":811,"type":42},{"text":342,"level":227},{"data":813,"type":217},{"text":345},{"data":815,"type":217},{"text":348},{"data":817,"type":265},{"code":351},{"data":819,"type":217},{"text":354},{"data":821,"type":42},{"text":357,"level":227},{"data":823,"type":217},{"text":360},{"data":825,"type":238},{"items":826,"style":237},[364,365,366,367,368],{"data":828,"type":217},{"text":371},{"data":830,"type":265},{"code":374},{"data":832,"type":42},{"text":377,"level":227},{"data":834,"type":238},{"items":835,"style":237},[381,382,383,384,385,386],{"data":837,"type":217},{"text":389},{"data":839,"type":255},{"text":392,"caption":393},{"data":841,"type":42},{"text":396,"level":227},{"data":843,"type":217},{"text":399},{"data":845,"type":217},{"text":402},{"data":847,"type":42},{"text":405,"level":227},{"data":849,"type":217},{"text":408},{"data":851,"type":411},{},{"data":853,"type":420},{"link":414,"meta":854},{"image":855,"title":418,"description":419},{"url":417},{"data":857,"type":420},{"link":423,"meta":858},{"image":859,"title":426,"description":427},{"url":417},{"data":861,"type":420},{"link":430,"meta":862},{"image":863,"title":433,"description":434},{"url":417},{"data":865,"type":420},{"link":437,"meta":866},{"image":867,"title":440,"description":441},{"url":417},{"data":869,"type":420},{"link":444,"meta":870},{"image":871,"title":447,"description":448},{"url":417},{"data":873,"type":420},{"link":451,"meta":874},{"image":875,"title":454,"description":455},{"url":417},"Post erfolgreich abgerufen",{"items":878,"source":907,"manualIds":908,"manualMatchedIds":909},[879,886,893,900],{"id":880,"slug":881,"title":882,"excerpt":883,"featuredImage":884,"publishedAt":885},"383","canonical-architecture-url-design-resolver-logic-api-scalability-specification","Architecture Canonique, Conception d'URL, Logique de Résolution, Spécification d'API et d'Évolutivité","Architecture de découverte géolocalisée pour les portails multi-locataires. Définit les URL canoniques, la logique de résolution, la stratégie de mise en cache et un modèle de lecture géo sans couplage CMS ni refactorisation de base de données. Conçue pour la stabilité SEO, l'évolutivité et les futures extensions comme la réservation et les cartes.","\u002Fuploads\u002F2026\u002F01\u002Fcanonical-architecture-url-design-resolver-logic-api-scalability-specification-1769890763607-7rghbp.webp","2026-01-31T06:12:00.000Z",{"id":887,"slug":888,"title":889,"excerpt":890,"featuredImage":891,"publishedAt":892},"381","enterprise-grade-multi-tenant-architecture-for-an-international-platform","Enterprise-Grade Multi-Tenant Architecture for an International Platform","Loving Rocks is an enterprise-grade wedding platform designed with a true multi-tenant architecture, isolated databases per tenant, and built-in internationalization for global scalability, security, and long-term operational stability.","\u002Fuploads\u002F2026\u002F01\u002Fenterprise-grade-multi-tenant-architecture-for-an-international-platform-1769789121298-b6v7ak.webp","2026-01-30T12:04:00.000Z",{"id":894,"slug":895,"title":896,"excerpt":897,"featuredImage":898,"publishedAt":899},"459","ollama-is-not-the-product-building-production-ready-open-llm-applications","Ollama n'est pas le produit : construire des applications Open-LLM prêtes pour la production","Exécuter un modèle local avec Ollama est facile. Construire une application Open-LLM prête pour la production est plus difficile : cela nécessite du RAG, du contrôle d'accès, de l'abstraction de fournisseur, de l'évaluation, de la journalisation, de la discipline de déploiement et une couche applicative contrôlée autour du modèle.","\u002Fuploads\u002F2026\u002F06\u002Follama-is-not-the-product-building-production-ready-open-llm-applications-1782679361640-h0usqf.webp","2026-06-28T16:39:00.000Z",{"id":901,"slug":902,"title":903,"excerpt":904,"featuredImage":905,"publishedAt":906},"445","qwen-3-6-in-production-release-runbook-ai-rollback-and-llmops-versioning","Qwen 3.6 en production : Runbook de déploiement, Rollback IA et Versionnage LLMOps","Qwen 3.6 n'est pas seulement une autre mise à jour de modèle. C'est à la fois un événement de déploiement, un scénario de rollback et un problème de versionnage. Cet article explique comment Qwen 3.6 doit être géré en production à travers la discipline LLMOps, la traçabilité des prompts et des modèles, le déploiement contrôlé et une préparation au rollback basée sur des preuves.","\u002Fuploads\u002F2026\u002F02\u002Fnew-qwen-3-5-plus-1771515512741-dcbi9p.webp","2026-05-04T02:49:00.000Z","fallback",[],[]]