🧠 Domain Driven Design: Программируем на языке бизнеса

Главная проблема IT: Разработчики говорят на языке таблиц (INSERT, Foreign Key, DTO), а бизнес на языке денег и процессов («Провести проводку», «Списать остаток»).

DDD (Предметно-ориентированное проектирование) - это попытка убрать переводчика.


🗣 1. Ubiquitous Language (Единый язык)

Это фундамент. Код должен звучать так же, как речь эксперта.

🔴Плохо (CRUD-мышление):
• Бизнес: "Клиент сменил адрес доставки".
• Код: user.setAddress("New York"); userRepo.save(user);


🔴Хорошо (DDD):
• Код: user.relocateTo(new Address("New York"));

Методы должны называться глаголами бизнеса, а не сеттерами.


📦 2. Bounded Context (Ограниченный контекст)

Самая большая ошибка новичка - создать один класс Product на всё приложение.

🔴Для Продаж: Товар - это цена, описание, картинки.
🔴Для Склада: Товар - это вес, габариты, номер полки.
🔴Для Бухгалтерии: Товар - это актив, амортизация, инвентарный номер.

В DDD мы не делаем монстра. Мы создаем разные модели для разных контекстов.

🔴SalesContext.Product
🔴WarehouseContext.StockItem

Эти модели могут даже иметь разные ID и общаться друг с другом только через события (Kafka).


🏗 3. Tactical DDD (Строительные блоки)

Как писать код внутри контекста?

A. Entity (Сущность)

Объект, у которого есть Identity (ID).
Если у двух людей одинаковое имя, это все равно два разных человека (разные ID).

🔴Пример: User, Order.
🔴Они живут долго, меняют свое состояние, но остаются собой.

B. Value Object (Объект-значение)

Объект, который определяется только своими данными. У него нет ID. Он неизменяем (Immutable).

🔴Пример: Money, Address, Color.
🔴Если у меня есть 100 рублей и у вас 100 рублей - это одни и те же 100 рублей. Нам не важно, какая именно это купюра.
🔴Правило: Не используйте примитивы! Вместо String email используйте класс EmailAddress. Там можно спрятать валидацию.

C. Aggregate (Агрегат)

Это кластер объектов, которые живут и умирают вместе.

🔴Пример: Заказ (Order) + Позиции заказа (OrderItems).
🔴Aggregate Root (Корень): Это главный объект (Order).
🔴Правило: Извне можно обращаться только к Корню. Нельзя получить ссылку на OrderItem и изменить его цену напрямую. Вы должны сказать: order.changeItemPrice(...). Это гарантирует целостность данных.


🩸 Anemic vs Rich Model (Анемичная vs Богатая модель)

❌ Анемичная (Стандартный Spring):
Класс — это просто мешок с геттерами и сеттерами. Вся логика лежит в Service.

// Service
public void completeOrder(Long id) {
    Order order = repo.findById(id);
    if (order.getStatus() != PAID) throw ...
    order.setStatus(COMPLETED); // Кто угодно может поменять статус!
    repo.save(order);
}

✅ Богатая (DDD):
Логика и валидация живут внутри Сущности. Сервис просто координирует работу.

// Entity
public void complete() {
    if (this.status != PAID) throw new DomainException("Не оплачено!");
    this.status = COMPLETED;
    // Можно даже вернуть событие OrderCompletedEvent
}

// Service
public void completeOrder(Long id) {
    Order order = repo.findById(id);
    order.complete(); // Вся бизнес-логика внутри
    repo.save(order);
}

🔥 Итог

DDD - это сложно, но необходимо для больших проектов.

1. Говорите на языке бизнеса (Ubiquitous Language).
2. Разделяйте модели (Bounded Contexts).
3. Используйте Value Objects вместо примитивов.
4. Прячьте логику внутрь Rich Domain Model.

#Architecture #DDD #DomainDrivenDesign #Java #Microservices

📲 Мы в MAX

👉@BookJava