DDD у Go. частина 1: Як FixDrive долає складність ride-hailing домену та уникає «великої купи бруду»

package domain

import (
    "time"
)

// RideID — унікальний ідентифікатор поїздки
type RideID string

// RideStatus відображає життєвий цикл поїздки в ride-hailing сервісі
type RideStatus string

const (
    RideStatusPending   RideStatus = "pending"    // Пошук водія
    RideStatusAccepted  RideStatus = "accepted"   // Водій знайдений і прямує до клієнта
    RideStatusInProgress RideStatus = "in_progress" // Пасажир у машині, їдуть
    RideStatusCompleted  RideStatus = "completed"   // Поїздка успішно завершена
    RideStatusCancelled  RideStatus = "cancelled"   // Скасовано пасажиром або водієм
)

// Ride — основна сутність для FixDrive.tech
type Ride struct {
    ID           RideID
    PassengerID  string       // Хто замовляє
    DriverID     string       // Хто виконує (може бути порожнім на етапі Pending)
    
    // Маршрут
    PickupPoint  string       // Точка А (адреса або координати)
    Destination  string       // Точка Б
    
    // Фінанси та сервіс
    Price        float64      // Вартість поїздки
    Currency     string       // Наприклад, "UAH"
    ServiceType  string       // Економ, Стандарт, Комфорт, Бізнес
    
    Status       RideStatus
    
    CreatedAt    time.Time    // Час замовлення
    StartedAt    *time.Time   // Час, коли пасажир сів у авто
    FinishedAt   *time.Time   // Час завершення
}

Як це працює в архітектурі

Цей код належить до рівня Domain, тобто він описує правила бізнесу. Він не знає про базу даних чи API. Будь-яка інша частина програми (наприклад, сервіс розрахунку ціни або сервіс призначення водія) буде використовувати саме цю структуру як «єдине джерело істини»

package usecase
import (
    "context"
    "domain"
)
type RideUsecase struct {
    rideRepo      domain.RideRepository
    passengerRepo domain.PassengerRepository
    pricingService domain.PricingService // Специфічно для таксі
}
func (u *RideUsecase) CreateRideDraft(ctx context.Context, passengerID string, pickup, destination string) (*domain.Ride, error) {
    // 1. Перевіряємо, чи існує пасажир та чи не заблокований він
    passenger, err := u.passengerRepo.GetByID(ctx, passengerID)
    if err != nil {
        return nil, domain.ErrPassengerNotFound
    }
// 2. Розраховуємо ціну (аналог вибору категорії/ціни в оголошеннях)
    price, err := u.pricingService.Calculate(ctx, pickup, destination)
    if err != nil {
        return nil, err
    }
// 3. Створюємо доменну сутність через конструктор (Business Logic)
    ride, err := domain.NewRide(passenger.ID, pickup, destination, price)
    if err != nil {
        return nil, err
    }
// 4. Зберігаємо чернетку в базу через репозиторій
    if err := u.rideRepo.Save(ctx, ride); err != nil {
        return nil, err
    } return ride, nil
}

Репозиторій тепер — це просто «тупа» обгортка над базою даних. Він отримує готовий об’єкт Ride і кладе його в таблицю.

Валідація стану: Перед створенням поїздки ми можемо перевірити, чи немає у пасажира вже активної поїздки (бізнес-правило), що неможливо зробити всередині простого методу Save

• Pricing Service: У таксі ціна — залежить від відстані, заторів та попиту. Винесення логіки в Usecase дозволяє легко вставити сервіс прорахунку.
• Валідація стану: Перед створенням поїздки ми можемо перевірити, чи немає у пасажира вже активної поїздки (бізнес-правило), що неможливо зробити всередині простого методу

Інкрементальна розробка базується на ідеї поступового розширення функціональності системи. Продукт не створюється як монолітний блок — він «виростає» через окремі частини, кожна з яких додає нову цінність. Наприклад, у сервісі замовлення поїздок спочатку можна реалізувати базове створення заявки без складної логіки. Далі — додати розрахунок вартості, потім валідацію користувача, і вже після цього — статуси поїздки. Кожен такий крок є завершеним інкрементом: система стає функціональнішою, і її вже можна використовувати.

Ітеративна розробка, натомість, зосереджена не на розширенні, а на вдосконаленні. Та сама функція проходить кілька етапів розвитку: від простого прототипу до стабільного та оптимізованого рішення. Спочатку логіка може бути мінімальною, без глибокої обробки помилок чи оптимізації. З кожною ітерацією додаються перевірки, покращується структура коду, з’являється логування, метрики, підвищується продуктивність. У результаті функція залишається тією ж, але її якість суттєво зростає.

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

Висновок

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті