Реалізація 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 — без спільної мови команда буде плутатися в термінах.
• Ігнорування тестування — без модульних тестів втрачається сенс ізоляції логіки.

Замовте консультацію для оцінки вашого проєкту — ми підберемо оптимальний обсяг впровадження та сплануємо дорожню карту. Зв'яжіться з нами для безкоштовного аудиту поточної архітектури. Наші інженери гарантують якість та дотримання термінів.