[{"data":1,"prerenderedAt":130},["ShallowReactive",2],{"$fgd75q5c6I23sLkkvXDmxDmr6peTuSc_ZQfNg6jIrS14":3},{"article":4,"similarArticles":16,"tagCounts":127},{"slug":5,"content":6,"notes":7,"groupedNotes":8,"title":9,"date":10,"description":11,"tags":12,"author":15},"stemmler-khalil-client-side-architecture-basics-i","\u003Cp>Данная статья представляет собой введение в основы архитектуры на стороне клиента, в которой автор рассматривает проблемы существующих подходов и предлагает пути их решения.\u003C\u002Fp>\n\u003Ch4 id=\"проблема-современных-стандартов-mvc-и-mvp\">Проблема современных стандартов (MVC и MVP)\u003C\u002Fh4>\n\u003Cp>Большинство разработчиков знакомы с паттерном \u003Cstrong>Model-View-Controller (MVC)\u003C\u002Fstrong>, который разделяет приложение на данные\u002Fлогику (модель), представление (вид) и обработку событий (контроллер). Для клиентских приложений часто используется его производная — \u003Cstrong>Model-View-Presenter (MVP)\u003C\u002Fstrong>, где вид создает события, которые обновляют модель, а модель, в свою очередь, обновляет вид.\u003C\u002Fp>\n\u003Cp>Основная проблема этих паттернов заключается в том, что они \u003Cstrong>слишком универсальны\u003C\u002Fstrong>. В них \u003Cstrong>компонент «Модель» (M) перегружен обязанностями\u003C\u002Fstrong>, что создает неопределенность: разработчики часто не знают, какой инструмент за какую задачу отвечает.\u003C\u002Fp>\n\u003Ch4 id=\"задачи-модели-в-клиентских-приложениях\">Задачи «Модели» в клиентских приложениях\u003C\u002Fh4>\n\u003Cp>В современных веб-приложениях «модель» выполняет множество функций:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Управление состоянием:\u003C\u002Fstrong> получение, обновление и реактивность данных.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Сетевое взаимодействие:\u003C\u002Fstrong> запросы к API, обработка ответов, индикация загрузки и ошибок, а также оптимистичные обновления.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Поведение модели (логика):\u003C\u002Fstrong>\n\u003Cul>\n\u003Cli>\u003Cstrong>Логика взаимодействия (прикладная):\u003C\u002Fstrong> реакция на действия пользователя (например, валидация перед отправкой API-вызова).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Доменная логика:\u003C\u002Fstrong> правила, не зависящие от самого приложения, а проистекающие из предметной области (например, правила хода шахматных фигур).\u003C\u002Fli>\n\u003C\u002Ful>\n\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Аутентификация и авторизация:\u003C\u002Fstrong> проверка прав доступа как в представлении, так и на уровне логики взаимодействия.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch4 id=\"необходимость-общего-языка\">Необходимость общего языка\u003C\u002Fh4>\n\u003Cp>Несмотря на обилие инструментов (React hooks, Redux, Apollo Client и др.), разработчикам не хватает \u003Cstrong>общего языка\u003C\u002Fstrong> для описания архитектурных концепций. Наличие такого понимания позволило бы лучше проектировать приложения, четко распределять задачи между инструментами и избегать глубокого проникновения одной проблемы в другую.\u003C\u002Fp>\n\u003Ch4 id=\"решение-уроки-бэкенд-разработки\">Решение: уроки бэкенд-разработки\u003C\u002Fh4>\n\u003Cp>Автор отмечает, что проблемы «размытой модели» уже решались в бэкенд-разработке на протяжении последних 30 лет. Когда стандартного MVC стало недостаточно, разработчики перешли к более продвинутым архитектурам, таким как \u003Cstrong>Чистая архитектура (Clean Architecture)\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>Ключевой принцип здесь — \u003Cstrong>разделение модели на слои\u003C\u002Fstrong>:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Доменный слой (Domain):\u003C\u002Fstrong> чистая бизнес-логика.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Прикладной слой (Application):\u003C\u002Fstrong> логика конкретного приложения.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Инфраструктурный слой (Infrastructure) \u002F Адаптеры:\u003C\u002Fstrong> интеграция внешних зависимостей (API, базы данных, кеши), которые должны быть отделены от ядра приложения.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch4 id=\"цели-клиентской-архитектуры\">Цели клиентской архитектуры\u003C\u002Fh4>\n\u003Cp>Архитектура — это не просто организация файлов, а способ написания \u003Cstrong>тестируемого, гибкого и поддерживаемого кода\u003C\u002Fstrong>:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Тестируемость:\u003C\u002Fstrong> Четкое разделение ответственности позволяет писать \u003Cstrong>юнит-тесты\u003C\u002Fstrong> для сложной логики (например, шахматных правил), в то время как простые CRUD-приложения могут ограничиваться интеграционными тестами.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Гибкость:\u003C\u002Fstrong> Возможность легко заменять компоненты представления или изменять поведение модели (например, подменять реальный API на мок-объекты для тестов).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Поддерживаемость:\u003C\u002Fstrong> Баланс между строгой структурой и удобством разработки (Developer Experience). Слишком жесткие правила могут снизить скорость работы, но отсутствие структуры мешает развитию приложения в долгосрочной перспективе.\u003C\u002Fli>\n\u003C\u002Ful>",[],{},"Client-Side Architecture Basics: I. Architecture (2020)","2026-07-22","Проблемы MVC и MVP во фронтенде и путь к клиентской архитектуре — разделение домена, приложения и инфраструктуры.",[13,14],"Frontend","Программирование","Stemmler, Khalil",[17,22,28,32,39,44,49,55,60,67,73,78,82,86,92,99,106,113,117,123],{"slug":18,"title":19,"date":10,"author":20,"tags":21},"mdn-contributors-css-performance-optimization-2025","CSS performance optimization (2025)","MDN Contributors",[13,14],{"slug":23,"title":24,"date":10,"author":25,"tags":26},"simpson-kyle-you-don-t-know-js-async-performance-2015","You Don't Know JS: Async & Performance (2015)","Simpson, Kyle",[27,13,14],"Javascript",{"slug":29,"title":30,"date":10,"author":15,"tags":31},"stemmler-khalil-client-side-architecture-basics-ii","Client-Side Architecture Basics: II. Principles (2020)",[13,14],{"slug":33,"title":34,"date":35,"author":36,"tags":37},"notashelf-taste-is-all-that-s-left-2026","Taste Is All That's Left (2026)","2026-08-10","notashelf",[38,14],"AI",{"slug":40,"title":41,"date":10,"author":42,"tags":43},"brooks-frederick-p-jr-the-mythical-man-month-essays-on","The Mythical Man-Month: Essays on Software Engineering (1995)","Brooks, Frederick P., Jr.",[14],{"slug":45,"title":46,"date":10,"author":47,"tags":48},"spolsky-joel-the-law-of-leaky-abstractions-2002","The Law of Leaky Abstractions (2002)","Spolsky, Joel",[14],{"slug":50,"title":51,"date":52,"author":53,"tags":54},"kholmatova-alla-design-systems-a-practical-guide-to","Design Systems: A practical guide to creating design languages for digital products","2026-07-16","Kholmatova, Alla",[14],{"slug":56,"title":57,"date":52,"author":58,"tags":59},"martin-robert-c-clean-code-a-handbook-of-agile-software","Clean Code: A Handbook of Agile Software Craftsmanship (2025)","Martin, Robert C.",[14],{"slug":61,"title":62,"date":63,"author":64,"tags":65},"corbin-henry-the-imago-templi-in-confrontation-with-secular","The Imago Templi in Confrontation with Secular Norms; Temple and Contemplation (1986)","2026-08-20","Corbin, Henry",[66],"Корбен",{"slug":68,"title":69,"date":63,"author":70,"tags":71},"damasio-antonio-r-descartes-error-emotion-reason-and-the","Descartes' Error: Emotion, Reason, and the Human Brain (1994)","Damasio, Antonio R.",[72],"Психология",{"slug":74,"title":75,"date":63,"author":76,"tags":77},"dixon-thomas-alexander-bain-herbert-spencer-charles-darwin","Alexander Bain, Herbert Spencer, Charles Darwin (from «From Passions to Emotions», 2003)","Dixon, Thomas",[72],{"slug":79,"title":80,"date":63,"author":76,"tags":81},"dixon-thomas-from-passions-to-emotions-the-creation-of-a","From Passions to Emotions. The Creation of a Secular Psychological Category (2003)",[72],{"slug":83,"title":84,"date":63,"author":76,"tags":85},"dixon-thomas-teoriya-dzheimsa-makkosha-iz-from-passions-to","Теория Джеймса Маккоша (из «From Passions to Emotions», 2003)",[72],{"slug":87,"title":88,"date":63,"author":89,"tags":90},"donnellan-brendan-friedrich-nietzsche-and-paul-ree","Friedrich Nietzsche and Paul Rée. Cooperation and Conflict (1982)","Donnellan, Brendan",[91],"Ницше",{"slug":93,"title":94,"date":63,"author":95,"tags":96},"heilbroner-robert-l-do-machines-make-history-1967","Do Machines Make History (1967)","Heilbroner, Robert L.",[97,98],"Политика","История",{"slug":100,"title":101,"date":63,"author":102,"tags":103},"kolesnitsa-bez-khozyaina","Колесница без хозяина","NotebookLM",[104,105],"Платон","Индия",{"slug":107,"title":108,"date":63,"author":109,"tags":110},"sanders-robert-h-an-alternative-to-dark-matter-modified","An Alternative to Dark Matter: Modified Newtonian Dynamics (from «The Dark Matter Problem. A Historical Perspective», 2009)","Sanders, Robert H.",[111,112],"Космология","Физика",{"slug":114,"title":115,"date":63,"author":109,"tags":116},"sanders-robert-h-deconstructing-cosmology-2016","Deconstructing Cosmology (2016)",[111,112],{"slug":118,"title":119,"date":63,"author":120,"tags":121},"serkov-a-i-dumskoe-masonstvo-i-vremennoe-pravitelstvo-iz","«Думское масонство» и Временное правительство (из «Истории русского масонства. 1845–1945», 1997)","Серков, А.И.",[122,98],"Масонство",{"slug":124,"title":125,"date":63,"author":120,"tags":126},"serkov-a-i-masonstvo-mikhaila-bakunina-iz-istorii-russkogo","Масонство Михаила Бакунина (из «Истории русского масонства. 1845–1945», 1997)",[122,98],{"Frontend":128,"Программирование":129},4,9,1787241654257]