Реализация Domain-Driven Design (DDD) для веб-приложения

Реализация Domain-Driven Design (DDD) для веб-приложения

Мы сталкивались с проектом, где бизнес-логика была размазана по контроллерам и сервисам. Каждое изменение требовало часов поиска, кто где обновляет статус заказа. DDD решил эту проблему, сделав код отражением бизнес-процессов. Ниже — наш опыт реализации DDD для веб-приложений с примерами на TypeScript.

Domain-Driven Design — методология проектирования ПО, при которой архитектура системы отражает бизнес-домен. Код говорит на том же языке, что и эксперты предметной области. Не «обновить запись в таблице users», а «заблокировать аккаунт за нарушение политики». DDD оправдан для сложных доменов — e-commerce с нетривиальными правилами ценообразования, финансовых систем, SaaS с гибкими тарифами. Мы применяли DDD в проектах с требованиями высокой целостности и частыми изменениями. Наши инженеры имеют 7+ лет опыта в DDD-проектах и выполнили более 40 внедрений для клиентов из разных отраслей. Domain-Driven Design — это не панацея, но мощный инструмент для сложных систем.

Когда DDD необходим

Если ваш проект обрабатывает тысячи заказов с нестандартными правилами скидок, налогами и ограничениями — DDD помогает структурировать хаос. Например, в одном из проектов мы уменьшили время на внесение изменений в логику ценообразования в 3 раза, а количество ошибок при релизах снизилось на 70%.

Управление сложностью с помощью DDD

DDD вводит чёткие границы — Bounded Context. Внутри каждого контекста термины имеют строгий смысл. Например, «Продукт» в каталоге — это описание и фото, а в заказах — SKU и цена. Контексты взаимодействуют через антикоррупционный слой. Это изолирует изменения и ускоряет разработку. Эрик Эванс, Domain-Driven Design подчёркивает, что Bounded Context — ключ к управлению сложностью.

Сравнение DDD и CRUD

Процесс внедрения DDD

1. Выделите самый сложный bounded context (например, управление заказами).
2. Определите ubiquitous language с бизнес-экспертами — запишите все термины.
3. Спроектируйте агрегаты и value objects, зафиксируйте инварианты.
4. Напишите модульные тесты для доменной логики (покрытие 90%+).
5. Интегрируйте контексты через доменные события и антикоррупционный слой.

Почему стоит внедрять DDD постепенно?

DDD требует дисциплины. Не стоит покрывать всю систему сразу. Начните с самого сложного контекста — это даст быстрый результат и 60% снижения ошибок в этой области. Постепенно количество багов уменьшается на 40–50% по сравнению с CRUD-подходом. Мы рекомендуем выделить 2–3 ключевых агрегата и построить вокруг них остальную архитектуру. Наши клиенты экономят до 40% бюджета на поддержку после внедрения DDD.

Какие проблемы решает DDD?

Основная проблема — размытая бизнес-логика, когда изменения затрагивают множество сервисов. DDD вводит чёткие границы контекстов и инкапсулирует правила в агрегатах. Это снижает стоимость изменений на 30–50% и ускоряет вывод новых фич.

Строительные блоки

Entity

Объект с идентичностью, сохраняющейся при изменении атрибутов:

class Order {
    private readonly _id: OrderId;
    private _status: OrderStatus;
    private _items: OrderItem[] = [];
    private _domainEvents: DomainEvent[] = [];

    constructor(id: OrderId, customerId: CustomerId) {
        this._id = id;
        this._status = OrderStatus.Draft;
        this.raise(new OrderCreatedEvent(id, customerId));
    }

    addItem(product: Product, quantity: Quantity): void {
        if (this._status !== OrderStatus.Draft) {
            throw new OrderNotEditableError(this._id);
        }
        if (quantity.isZero()) {
            throw new InvalidQuantityError();
        }
        const existing = this._items.find(i => i.productId.equals(product.id));
        if (existing) {
            existing.increaseQuantity(quantity);
        } else {
            this._items.push(new OrderItem(product.id, product.price, quantity));
        }
    }

    submit(): void {
        this.ensureCanTransitionTo(OrderStatus.Submitted);
        if (this._items.length === 0) throw new EmptyOrderError();
        this._status = OrderStatus.Submitted;
        this.raise(new OrderSubmittedEvent(this._id, this.calculateTotal()));
    }
}

Value Object

Объект без идентичности, определяемый значениями. Неизменяемый:

class Money {
  private constructor(
    private readonly _amount: number,
    private readonly _currency: Currency
  ) {
    if (_amount < 0) throw new NegativeAmountError();
  }

  static of(amount: number, currency: Currency): Money {
    return new Money(amount, currency);
  }

  add(other: Money): Money {
    if (!this._currency.equals(other._currency)) {
      throw new CurrencyMismatchError();
    }
    return new Money(this._amount + other._amount, this._currency);
  }
}

Domain Service

Операция, не принадлежащая ни одной сущности:

class OrderPricingService {
  constructor(
    private discountRepo: DiscountRepository,
    private taxService: TaxCalculationService
  ) {}

  async calculateTotal(order: Order, customer: Customer): Promise<PricingResult> {
    const discounts = await this.discountRepo.findApplicable(
      customer.segment,
      order.items
    );

    let subtotal = order.items.reduce(
      (sum, item) => sum.add(item.price.multiply(item.quantity.value)),
      Money.zero(Currency.USD)
    );

    const discountAmount = this.applyDiscounts(subtotal, discounts, customer);
    const taxAmount = await this.taxService.calculate(subtotal, customer.address);

    return new PricingResult(subtotal, discountAmount, taxAmount);
  }
}

Repository

Абстракция доступа к хранилищу для агрегата:

interface OrderRepository {
  findById(id: OrderId): Promise<Order | null>;
  findByCustomer(customerId: CustomerId, options?: FindOptions): Promise<Order[]>;
  save(order: Order): Promise<void>;
}

class PostgresOrderRepository implements OrderRepository {
  async findById(id: OrderId): Promise<Order | null> {
    const row = await this.db.queryOne(
      'SELECT * FROM orders WHERE id = $1',
      [id.value]
    );
    return row ? this.toDomain(row) : null;
  }
}

Application Layer

Тонкий слой, оркестрирующий доменные объекты:

class PlaceOrderUseCase {
  async execute(dto: PlaceOrderDto): Promise<PlaceOrderResult> {
    const customer = await this.customerRepo.findById(
      CustomerId.from(dto.customerId)
    );
    if (!customer) throw new CustomerNotFoundError(dto.customerId);

    const order = new Order(OrderId.generate(), customer.id);
    for (const item of dto.items) {
      const product = await this.productRepo.findById(ProductId.from(item.productId));
      order.addItem(product, Quantity.of(item.quantity));
    }

    const pricing = await this.pricingService.calculateTotal(order, customer);
    order.applyPricing(pricing);
    order.submit();

    await this.orderRepo.save(order);
    await this.eventBus.publishAll(order.pullDomainEvents());

    return {
      orderId: order.id.value,
      total: order.total,
    };
  }
}

Сроки и стоимость

Стоимость рассчитывается индивидуально и зависит от сложности домена. В среднем внедрение DDD окупается за 6–12 месяцев за счёт снижения стоимости поддержки и ускорения разработки новых фич.

Что вы получаете в результате

Типичные ошибки при внедрении DDD

• Попытка покрыть всю систему сразу — начинайте с самого сложного контекста.
• Пренебрежение Ubiquitous Language — без общего языка команда будет путаться в терминах.
• Игнорирование тестирования — без модульных тестов теряется смысл изоляции логики.

Закажите консультацию для оценки вашего проекта — мы подберём оптимальный объём внедрения и спланируем дорожную карту. Свяжитесь с нами для аудита текущей архитектуры. Наши инженеры гарантируют качество и соблюдение сроков.