Ответ.

Domain-Driven Design (DDD) — это подход к проектированию программных систем, который концентрируется на предметной области и её логике. DDD разбивает сложные предметные области на связанные, но независимые ограниченные контексты (bounded contexts). В каждом контексте разрабатывается свой собственный язык (Ubiquitous Language), согласованный с экспертами домена. Основные строительные блоки DDD:

• Entity: объект с уникальным идентификатором и жизненным циклом (например, заказ).
• Value Object: неизменяемый объект без уникального идентификатора (например, адрес доставки).
• Aggregate & Aggregate Root: совокупность объектов, для которой все изменения проходят через корень агрегата.
• Repository: слой для работы с хранилищем агрегатов.
• Service: операции, не относящиеся к конкретному объекту.

Ограниченные контексты часто представляют собой отдельные микросервисы, взаимодействующие через явно описанные API или события.

Пример кода на Java (Spring):

// Пример Value Object
@Embeddable
public class Address {
  private String city;
  private String street;
  // ... конструкторы, equals, hashCode
}

// Пример Entity с Aggregate Root
@Entity
public class Order {
  @Id
  private Long id;
  @Embedded
  private Address deliveryAddress;
  // ... бизнес-методы
}

Ключевые особенности:

• Чёткая декомпозиция предметной области и контейнеризация логики.
• Упрощение развития и масштабирования за счёт изоляции.
• Повышение согласованности технического и бизнес-языка команды.

Вопросы с подвохом.

Все ли объекты в DDD являются Entity?

Нет, существуют также Value Objects — они не имеют уникальности, их состояние полностью определяет идентичность.

Address a1 = new Address("Москва", "Арбат");
Address a2 = new Address("Москва", "Арбат");
System.out.println(a1.equals(a2)); // true

Означает ли разбиение на микросервисы применение DDD?

Нет, можно применять DDD и в рамках монолитного приложения, выстраивая внутренние границы контекстов.

Всегда ли нужен репозиторий для каждого агрегата?

Обычно да, но иногда агрегат можно полностью хранить как часть другого агрегата, если он не является корнем отдельной бизнес-транзакции.