Что такое чистая архитектура

Question

Что такое чистая архитектура

Тип вопроса: Архитектура Вероятность: 10% Категория: Frontend Разработчик

Ответ

Чистая архитектура — это подход к проектированию приложений, при котором код разделяется на слои с четкими границами и зависимостями, направленными внутрь (к бизнес-правилам). Основные принципы:

Независимость от фреймворков — бизнес-логика не зависит от UI, БД или внешних сервисов.
Тестируемость — легко тестировать без UI, API или БД.
Слои:
- Entities — бизнес-сущности (например, User).
- Use Cases — сценарии взаимодействия (например, AuthUser).
- Interface Adapters — преобразователи данных (DTO, Presenters).
- Frameworks & Drivers — UI, API, БД (React, Express, MongoDB).

Пример (TypeScript):

// Entity
interface User {
  id: string;
  name: string;
}

// Use Case
class AuthUser {
  execute(user: User) { /* логика авторизации */ }
}

// Adapter (HTTP)
class UserController {
  constructor(private authUser: AuthUser) {}
  login(req, res) {
    this.authUser.execute(req.body);
  }
}

Плюсы: гибкость, поддержка, тестируемость. Минусы: сложность для мелких проектов.

Ответ 18+ 🔞

Да ты послушай, что эти умники придумали! Чистая архитектура, блядь. Сидят, видимо, на очередном митапе, кофеек потягивают и такие: "А давайте сделаем так, чтобы наш код был независим от всего на свете, как будто он в вакууме живёт, ёпта!"

Суть в чём, а? В том, чтобы твоя самая важная, ядрёная бизнес-логика — типа как пользователя залогинить или деньги посчитать — чтобы она сидела в своей башне из слоновой кости и нихуя не знала про то, что у тебя там фронт на Реакте, база на MongoDB или API на Экспрессе. Абсолютная независимость, как монах в пещере, блядь!

Слои у них там, как в торте "Наполеон":

Сущности (Entities) — это вот сами ядра-изумруды, бизнес-объекты. Ну, Пользователь, Заказ, Деньги. Просто данные и правила, которые к ним прилагаются. Без всякой хуйни про базы или кнопки.
Сценарии использования (Use Cases) — это уже действия, ёбушки-воробушки! АвторизоватьПользователя, СоздатьЗаказ. Они знают про сущности и командуют ими. Это типа режиссёры нашей пьесы.
Адаптеры (Interface Adapters) — а это уже наши переводчики, блядь! Мир говорит с нами на языке HTTP-запросов или кликов мыши, а наши сценарии понимают только свои объекты. Вот адаптеры и переводят: взяли JSON из запроса, наколдовали из него нашу сущность User и отдали сценарию. И наоборот — результат сценария превратили обратно в JSON для фронта.
Фреймворки и драйверы (Frameworks & Drivers) — а это уже реальный мир, ёперный театр! Сам Реакт, Экспресс, MongoDB-драйвер. Всё это — просто детали реализации, которые можно выкинуть и заменить, как лампочку, если что. Главное, чтобы патрон (интерфейс) подходил.

Вот тебе пример, смотри, не усни только:

// 1. Сущность (Entity) — чистый бизнес-объект, нихуя не знает ни о чём
interface User {
  id: string;
  name: string;
  isActive: boolean;
}

// 2. Сценарий использования (Use Case) — знает ТОЛЬКО про сущности и бизнес-правила
class AuthUserUseCase {
  execute(user: User): boolean {
    // Вся логика тут. Никаких req, res, баз данных!
    return user.isActive; // Допустим, активных пускаем, неактивных — нахуй
  }
}

// 3. Адаптер (Контроллер) — переводчик между HTTP-миром и нашим Use Case
class UserController {
  constructor(private authUserUseCase: AuthUserUseCase) {} // Зависимость внедрили, красота!

  login(req, res) {
    // Превращаем сырые данные запроса в нашу чистую сущность
    const userFromRequest: User = {
      id: req.body.id,
      name: req.body.name,
      isActive: req.body.isActive
    };

    // Отдаём сущность сценарию и получаем чистый бизнес-результат
    const authResult = this.authUserUseCase.execute(userFromRequest);

    // Превращаем результат обратно в формат для HTTP-ответа
    res.json({ success: authResult });
  }
}
// 4. Фреймворк (Express, например) — где-то там снаружи, подключает контроллер к роуту. Он вообще в другом файле.

Плюсы, конечно, овердохуищные: гибкость пиздец, тестировать одно удовольствие (тестируй сценарии в полной изоляции), и поддерживать потом — как по маслу. Но, блядь, минус тоже огого: для пет-проекта или простого CRUD-сайта — это как ебать муху перфоратором. Оверкилл чистой воды, только время потратишь на эту слоёную структуру.

Так что, если проект не "сделать и забыть", а на долгую и сложную жизнь — может, и стоит помучиться. А если просто "хочу блог на выходные" — да похуй, пиши как привык, главное, чтобы работало, в рот меня чих-пых!