В чем разница между знакомыми тебе типами архитектуры?

Типы архитектур фронтенда

Архитектура — это структурная организация приложения, определяющая как компоненты взаимодействуют друг с другом. Рассмотрю основные типы, с которыми встречаюсь в реальных проектах.

MVC (Model-View-Controller)

Классическая архитектура, разделяющая приложение на три слоя:

• Model — данные и бизнес-логика
• View — пользовательский интерфейс
• Controller — связует Model и View

Проблема: View знает про Model, что создаёт тесную связанность. В современном фронтенде почти не используется.

MVVM (Model-View-ViewModel)

Улучшение MVC, где ViewModel — это промежуточный слой, который преобразует данные Model для View:

// Simplified MVVM example
class QuestionViewModel {
  constructor(questionModel) {
    this.model = questionModel;
    this.title = this.model.questionText; // трансформация
  }
  
  getFormattedAnswers() {
    return this.model.answers.map(a => ({
      id: a.id,
      displayText: a.text.toUpperCase()
    }));
  }
}

Преимущество: View зависит только от ViewModel, не от Model. Используется в Vue.js — реактивная привязка как раз MVVM паттерн.

Component-Based Architecture

Это то, что используется в React, Vue, Angular. Приложение — это древо компонентов:

// Компонент — единица переиспользования
export function QuestionCard({ question, onAnswer }) {
  return (
    <div className="card">
      <h2>{question.title}</h2>
      <button onClick={() => onAnswer(question.id)}>Ответить</button>
    </div>
  );
}

// Композиция
export function QuestionList({ questions }) {
  return (
    <div>
      {questions.map(q => <QuestionCard key={q.id} question={q} onAnswer={handleAnswer} />)}
    </div>
  );
}

Плюсы: переиспользование, тестируемость, модульность.

Layered Architecture (Слоистая)

Приложение разделено на слои (как в PrepBro):

┌─────────────────────────┐
│    Presentation Layer   │ (компоненты, UI)
├─────────────────────────┤
│   Application Layer     │ (хуки, сервисы)
├─────────────────────────┤
│     Domain Layer        │ (бизнес-логика, типы)
├─────────────────────────┤
│  Infrastructure Layer   │ (API, хранилище)
└─────────────────────────┘

Дependencies идут только вниз (Presentation → Infrastructure). Меняем API — меняем только Infrastructure, остальное не ломается.

Clean Architecture

Это расширение Layered с явной инверсией зависимостей:

• Entities — основные типы данных
• Use Cases — сценарии использования
• Interface Adapters — контроллеры, presenters
• Frameworks & Drivers — React, Angular, API

На фронтенде это выглядит как:domain/ → application/ → infrastructure/ → presentation/

Flux / Redux Pattern

State Management Architecture, нужна когда компоненты глубоко вложены и передача props становится ненужной:

// Redux-подобный паттерн
const initialState = { questions: [], loading: false };

function questionsReducer(state = initialState, action) {
  switch(action.type) {
    case FETCH_START:
      return { ...state, loading: true };
    case FETCH_SUCCESS:
      return { ...state, questions: action.payload, loading: false };
    default:
      return state;
  }
}

// Dispatch actions из компонентов
function fetchQuestions() {
  dispatch({ type: FETCH_START });
  api.getQuestions().then(data => 
    dispatch({ type: FETCH_SUCCESS, payload: data })
  );
}

Используется в: Redux, MobX, Zustand, Pinia.

Сравнение

Практика в PrepBro

Организуем код по принципам Clean Architecture с Component-Based подходом:

components/        # Presentation Layer
hooks/            # Application Layer (use cases)
lib/              # Infrastructure Layer (API, utils)
types/            # Domain Layer (типы, интерфейсы)

В каждой папке компонента: Component.tsx (UI) отдельно от логики (в хуках).

Выводы

Нет "лучшей" архитектуры — выбор зависит от масштаба проекта. Для фронтенда Component-Based + Layered — оптимум между простотой и масштабируемостью.