> Что такое DDD (Node.js, JavaScript)

Короткий ответ

DDD (Domain-Driven Design) - это подход к проектированию ПО, где основное внимание уделяется предметной области (domain) и её логике. Код строится вокруг бизнес-сущностей и правил, а не технических деталей. Для frontend DDD помогает организовать сложную бизнес-логику на клиенте, например, в формах или валидации, используя такие концепции как entity, value object и domain service.

Подробное объяснение

DDD (Domain-Driven Design) - это методология, предложенная Эриком Эвансом, которая фокусируется на моделировании программного обеспечения в соответствии с реальными бизнес-процессами. Основная идея - сделать код отражением предметной области, а не технической инфраструктуры.

Ключевые концепции DDD:

• Entity - объект с уникальным идентификатором и изменяемым состоянием (например, пользователь, заказ).
• Value Object - неизменяемый объект, определяемый своими атрибутами (например, адрес, деньги).
• Aggregate - группа связанных сущностей, обрабатываемая как единое целое.
• Domain Service - сервис, содержащий бизнес-логику, не привязанную к конкретной сущности.
• Repository - абстракция для доступа к данным (на frontend может быть заменён API-клиентом).
• Ubiquitous Language - единый язык между разработчиками и бизнесом, используемый в коде и обсуждениях.

Для frontend DDD особенно полезен в сложных приложениях с богатой бизнес-логикой (например, редакторы, системы управления контентом, финансовые дашборды). Он помогает отделить бизнес-правила от UI-логики и инфраструктуры (запросы к API, работа с localStorage).

На практике

На практике DDD на frontend реализуется через чёткое разделение слоёв:

• Domain layer - бизнес-сущности и правила (например, класс Order с методами calculateTotal и validateItems).
• Application layer - use cases (например, PlaceOrderUseCase, который вызывает методы домена и отправляет данные).
• Infrastructure layer - работа с API, localStorage, внешними библиотеками.
• UI layer - React-компоненты, которые только отображают данные и вызывают use cases.

Пример организации папок:

src/
  domain/
    entities/
      Order.js
    value-objects/
      Money.js
    services/
      DiscountService.js
  application/
    use-cases/
      PlaceOrderUseCase.js
  infrastructure/
    api/
      orderApi.js
  ui/
    components/
      OrderForm.jsx

DDD не требует строгого следования всем паттернам - достаточно начать с выделения бизнес-логики в отдельные классы и использования ubiquitous language.

Пример кода

JAVASCRIPT
// domain/entities/Order.js
class Order {
  constructor(id, items, discount) {
    this.id = id;
    this.items = items; // массив Value Object
    this.discount = discount; // Value Object
  }

  calculateTotal() {
    const subtotal = this.items.reduce((sum, item) => sum + item.price, 0);
    return this.discount.apply(subtotal);
  }

  validateItems() {
    return this.items.every(item => item.isValid());
  }
}

// domain/value-objects/Money.js
class Money {
  constructor(amount, currency = 'USD') {
    this.amount = amount;
    this.currency = currency;
    Object.freeze(this);
  }

  add(other) {
    if (other.currency !== this.currency) throw new Error('Currency mismatch');
    return new Money(this.amount + other.amount, this.currency);
  }
}

// application/use-cases/PlaceOrderUseCase.js
class PlaceOrderUseCase {
  constructor(orderRepository, paymentService) {
    this.orderRepository = orderRepository;
    this.paymentService = paymentService;
  }

  execute(orderData) {
    const order = new Order(
      orderData.id,
      orderData.items.map(item => new Money(item.price)),
      new Discount(orderData.discount)
    );
    if (!order.validateItems()) throw new Error('Invalid items');
    this.paymentService.charge(order.calculateTotal());
    this.orderRepository.save(order);
  }
}

Как отвечать на собеседовании

Для junior-позиции достаточно показать понимание базовых идей DDD и его применимости на frontend. Начни с краткого определения, затем приведи пример из своей практики (например, как ты выделил бизнес-логику валидации формы в отдельный класс). Упомяни, что DDD помогает избежать "god objects" и делает код тестируемым. Если спросят про сложности, скажи, что на frontend не всегда нужно строго следовать DDD - достаточно применять его элементы в сложных модулях.

Что проверяет интервьюер

Интервьюер проверяет:

• Понимание разницы между технической и бизнес-логикой.
• Умение применять DDD-концепции (entity, value object) в контексте frontend.
• Осознание, что DDD - это не серебряная пуля, а инструмент для сложных доменов.
• Способность объяснить, как DDD улучшает поддерживаемость кода.

Типичные ошибки

• Путать DDD с архитектурными паттернами (например, чистая архитектура) - DDD это про моделирование домена, а не про слои.
• Думать, что DDD нужен только на backend - на frontend он так же полезен для сложной логики.
• Переусложнять код, создавая entity для каждой мелочи (например, для простого списка задач).
• Игнорировать ubiquitous language - использовать технические термины вместо бизнес-терминов в коде.