7 мая 2026 г.·3 мин чтения

Domain-Driven Design на собеседовании системного аналитика

Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Карьерник — Duolingo для аналитиков: 10 минут в день тренируй SQL, Python, A/B, статистику, метрики и ещё 3 темы собеса. 1500+ вопросов в Telegram-боте. Бесплатно.

Содержание:

Зачем спрашивают на собесе SA

DDD — стандарт complex domain modeling. На собесе SA: «что такое bounded context», «зачем aggregates».

Идея DDD

Domain-Driven Design (Eric Evans 2003). Сложный business domain — главный driver software design.

Принципы:

  • Software отражает бизнес-domain.
  • Engineers и business говорят на одном языке.
  • Code structure следует business structure.
  • Большие domain'ы делятся на bounded contexts.

Strategic design

Высокий уровень — как разбить domain на subdomains.

Subdomain types:

  • Core domain. Главное business value (custom code).
  • Supporting subdomain. Помогает core, но не unique.
  • Generic subdomain. Common (auth, billing) — buy / use ready solutions.

Context map. Диаграмма subdomains и их relationships.

Bounded Context

Bounded context. Границы, где терминология / model имеют consistent смысл.

Customer в Sales context: имя, история покупок, скидки.
Customer в Billing context: имя, payment method, кредитный лимит.
Customer в Shipping context: имя, адрес, трекинг.

Один человек, разные модели в разных contexts. Каждый context — own data, own services, own team.

Context relationships:

  • Shared kernel. Общий код / model.
  • Customer/Supplier. Один зависит от другого.
  • Anti-corruption layer. Защита от грязной model partner'а.
  • Conformist. Принимает model partner'а.
Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Tactical patterns

Уровень кода / structure внутри context:

Entity. Объект с identity (Customer, Order). Identity определяется ID.

Value object. Без identity, immutable (Money, Address).

Aggregate. Cluster объектов, рассматривается как unit consistency. Имеет aggregate root — единственный entry point.

Order aggregate:
  - Order (root)
  - OrderItem
  - DeliveryDetails

Внешний код только видит Order, не OrderItem напрямую. Все изменения — через Order.

Repository. Абстрагирует storage aggregate'ов.

Domain service. Логика, не принадлежащая entity (например, transfer between accounts).

Domain event. Что-то значимое произошло (OrderShipped).

Ubiquitous language

Команда (developers + business) говорит на одном языке.

  • В коде variables / classes named как в domain.
  • Business stakeholder понимает diagrams.
  • Documentation использует те же terms.

«Customer registers» в business → Customer.register() в коде, не User.signup().

Когда применять

Подходит:

  • Сложный business domain (банки, страхование, supply chain).
  • Большая команда / multi-team.
  • Long-term project (3+ years).
  • Новая разработка / major refactor.

Overkill:

  • CRUD app.
  • Маленький proof-of-concept.
  • Команда без DDD опыта.

Связанные темы

FAQ

DDD vs микросервисы?

Bounded context часто == микросервис. Но DDD — design philosophy, микросервисы — implementation. Можно DDD в монолите.

Это официальная информация?

Нет. Статья основана на Eric Evans «Domain-Driven Design», Vaughn Vernon «Implementing DDD».

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.

Ещё по теме