[{"data":1,"prerenderedAt":53},["ShallowReactive",2],{"$f227Oew0_dp5TTGgbYLFwRNoP7Cb__ygZY1FUmsYYUX8":3},{"article":4,"relatedArticles":32,"tagCounts":51},{"slug":5,"content":6,"headings":7,"notes":24,"groupedNotes":25,"title":26,"date":27,"description":28,"tags":29,"author":31},"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>",[8,12,15,18,21],{"id":9,"text":10,"depth":11},"проблема-современных-стандартов-mvc-и-mvp","Проблема современных стандартов (MVC и MVP)",3,{"id":13,"text":14,"depth":11},"задачи-модели-в-клиентских-приложениях","Задачи «Модели» в клиентских приложениях",{"id":16,"text":17,"depth":11},"необходимость-общего-языка","Необходимость общего языка",{"id":19,"text":20,"depth":11},"решение-уроки-бэкенд-разработки","Решение: уроки бэкенд-разработки",{"id":22,"text":23,"depth":11},"цели-клиентской-архитектуры","Цели клиентской архитектуры",[],{},"Client-Side Architecture Basics: I. Architecture (2020)","2026-07-22","Проблемы MVC и MVP во фронтенде и путь к клиентской архитектуре — разделение домена, приложения и инфраструктуры.",[30],"Программирование","Stemmler, Khalil",[33,39,45],{"slug":34,"title":35,"description":36,"date":27,"author":37,"tags":38},"brooks-frederick-p-jr-the-mythical-man-month-essays-on","The Mythical Man-Month: Essays on Software Engineering (1995)","Классика управления разработкой — мифический человеко-месяц, хирургические бригады, концептуальная целостность и отсутствие серебряной пули.","Brooks, Frederick P., Jr.",[30],{"slug":40,"title":41,"description":42,"date":27,"author":43,"tags":44},"mdn-contributors-css-performance-optimization-2025","CSS performance optimization (2025)","Оптимизация CSS для быстрого рендера — блокировка отрисовки, reflow, анимации на GPU, шрифты и CSS Containment.","MDN Contributors",[30],{"slug":46,"title":47,"description":48,"date":27,"author":49,"tags":50},"simpson-kyle-you-don-t-know-js-async-performance-2015","You Don't Know JS: Async & Performance (2015)","Асинхронность и производительность в JavaScript — событийный цикл, промисы, генераторы, Web Workers и практики бенчмаркинга.","Simpson, Kyle",[30],{"Программирование":52},9,1785324880331]